[Pecan Pico 7] Solar powered camera tracker for balloons

[Giovanni]

Hi,

Problems in the I2C driver you mean?

You could consider moving to a newer STM32 like F7 or L4, those include a newer I2C peripheral that addresses several problems in the old one.

Giovanni

[FXCoder]

Hi Sven & Giovanni,
Thanks for the info on 9K6 Sven.
I have not trawled all of your code as yet so will go back and look more closely at the implementation of 9K6 soon.
BTW my Silicon Labs pico boards and development board have arrived so I'll get those setup as soon as a few more SMA cables and other bits arrive from China (my eBay account is getting a workover of late!)

A comment on I2C...
I just quickly put together a 20 x 4 line LCD driver for a Systronix 20 x 4 panel I sourced out of China (I2C adapter already fitted).
After some initial trouble it is now working reliably.
I now have handshake transfers functioning (checking busy flag of I2C converter on the LCD board to know when data can be written versus just using thread sleep delays and blind writes).

Things to note that I discovered in my initial I2C adventure:
1. I am currently using 2K2 PuP with 5V in I2C and relying on 5V tolerance of STM32F103RE which gives reasonable shape pulses on the scope
- I'll insert level shifters next and see how the performance and waveforms look after that
2. I set the I2C clock at 50,000 currently and found above 100,000 things stopped working with the LCD driver
3. I also use STD_DUTY_CYCLE rather than FAST_DUTY_CYCLE_2
4. Since the I2C #1 bus is planned to be used for low speed devices or even just simple UI (LCD/keypad) these lower specs are OK for me
- For example GPS would be fine at these transfer rates
- FYI I have a UBLOX NEO-M8N arriving anytime now so the high altitude operation should be fine (thanks for your comments on that Sven)
5. I will write a framework/manager to support devices registering/de-registering peripherals on the "slow" I2C
- These drivers/devices can then be accessed from other processes (threads) via the manager
- Then (all going well) peripherals like the LCD could be "mounted" and "ejected" as required (for example pre-flight setup).

I note in Pecan Pico code the I2C is set to 150,000 and FAST_DUTY_CYCLE_2.
Perhaps backing those settings off to lower spec will help (if there is only need for modest transfer speed).
I'm guessing the PAC1720 doesn't need to report power stats at high speed.
And of course (as you say Giovanni) switching to an F7 or L4 would be newer I2C silicon which should be more capable when it comes to fast I2C.

Stay in touch.

Regards,

Bob VK2ZXR

[A319]

Hi Giovanni and Bob,

Yes I'm planning to replace the STM32F429 with the F7 series, but I still have some chips left in my tray. I just wanna get rid all of them The layout compared to the current uC is the same, so I don't have change the pins.
The I2C problems are bad but I can handle them. L4 would be fine too but it doesn't come with the DCMI interface which I need for the cam.

I've updated the repository recently. I made a bugfix to the Si4464 packet handler which I use for the 9k6 modulation.
I also have a display but it's only an 128x64 OLED matrix. The font is really small. You actually need 3 magnifiers in series

1. Thats good. I also increased mine to 4k7 instead of 10k (which is the minimum you'd need). I need to keep the power consumption low but also need to keep everything working.

2/3. I've played around with the speeds and modes to get the maximum speed. I'm still not sure why 150k works and 200k or 400k does not. I never understood the clocking capabilities.

4. I have a lot of trouble using I2C with the ublox modules. For example
- I poll the GPS. GPS doesnt respond. (sometimes I have to poll it 100 times to get one valid answer)
- GPS has no receiption (signal level low). I poll the GPS. The GPS will answer. Then I generate a GPS singal (with a HF GPS simulator). I poll the GPS by I2C again. GPS doesn't answer anymore.
These are just 2 of several situations I noticed. I currently working with an ublox MAX6G but it also happened with the ublox MAX7C modules. I never had such problems when I used UART.

150k is definitely enough speed for all slaves. I poll the PAC1720 every 100ms and the GPS also has a lot of data being sent over the bus. But I never had problems with the data rate.

Regards
Sven

[A319]

And what I also want to append:

Very often I get I2C resets (at the uC). So I'm going to probe the problem (with my oscilloscope) but when I watch the problem with it, the problem is completely GONE. I figured out, than when I attach a 50...100pF capacitor between SCL and GND, the problem will go - except if there's moisture on the PCB (which happens in flight). So the problem is gone on day and occurs at night (when the temperature drops).

I also saw the same problem at work, when I worked with the STM32F4 series. Does anybody have an idea what could cause this?

Sven

[steved]

Very often I get I2C resets (at the uC). So I'm going to probe the problem (with my oscilloscope) but when I watch the problem with it, the problem is completely GONE. I figured out, than when I attach a 50...100pF capacitor between SCL and GND, the problem will go - except if there's moisture on the PCB (which happens in flight). So the problem is gone on day and occurs at night (when the temperature drops).

What value pullup do you have on the SCL line? It sounds as if moisture is sufficient to pull it down. Is your PCB conformally coated?

I also saw the same problem at work, when I worked with the STM32F4 series. Does anybody have an idea what could cause this?

I had some problems with the F4 which I think were due to ground noise. We normally use a 5V I2C bus between boards, with PCA9512 level shifters to 3V3.
Replaced the level shifter with a I2C isolator and the problem went away.

[A319]

Hi,

I actually planned 10k pullups but I also tried 4k7 and 3k3 which didn't help. I never did coating.

I don't know if Ground noise could be the problem. Is there a way to test this?
I also want to point out that power is very critical, so I want to avoid necessary parts on the board. And I think SPI/UART would be a nice option. Btw. the error only applies to the GPS (ublox MAX6G). All other components are performing well on the I2C bus.

Sven

[A319]

Good morning!

Due to my I2C investigation, I ordered some STM32F745 for testing. I got them yesterday and soldered one board with the new chip. It basically works with the STM32F746 linker script. I'm not sure if the linker has still a bug.

With the original STM32F4 build, I'll get following sizes:

Code: Select all

   text      data       bss       dec       hex   filename
  81596      1556    195496    278648     44078   build/ch.elf
Creating build/ch.list


But compiling the same code for the STM32F7 produces an error:

Code: Select all

/home/sven/crosscompile/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: build/ch.elf section `.bss' will not fit in region `ram3'
/home/sven/crosscompile/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: region `ram3' overflowed by 78816 bytes
collect2: error: ld returned 1 exit status
ChibiOS/os/common/startup/ARMCMx/compilers/GCC/rules.mk:239: recipe for target 'build/ch.elf' failed
make: *** [build/ch.elf] Error 1


If I reduce the image buffer by 80kB, it will fit

Code: Select all

Compiling config.c
Linking build/ch.elf
Creating build/ch.hex
Creating build/ch.bin
Creating build/ch.dmp

   text      data       bss       dec       hex   filename
  81636      1628    323460    406724     634c4   build/ch.elf
Creating build/ch.list

Done

Currently I can't say anything about I2C because I'm missing my UART level converter. So I can't debug whats going on at the moment.

I built 3 Boards with the older STM32F4 and one with the STM32F7. Some parts (chips) are missing while I forgot to reorder them.

[Giovanni]

Hi,

Look at the linker script, because the cache memory the BSS is allocated into a special memory that does not require caching in order to not have problems with DMA. This memory is limited to 64kB.

You can rearrange the memory and put BSS in the main RAM area but you need to keep the DMA-accessible buffers into the DTCM memory OR you will have to handle cache coherency manually (not a nice thing to do).

See this article: http://chibios.org/dokuwiki/doku.php?id ... _dma_guide

Giovanni

[FXCoder]

Hi guys,
Steve... good information on the isolators.
Pretty interesting devices (but not cheap).
I read through the spec sheet but could not find where they specify the actual frequency used in their RF isolation technique.
I can see if you have separate boards with different VCCs plus potential for ground noise via wired GND between boards, then those isolators would be the go.

Sven,
This is just me speculating but I wonder if your issues are more to do with crosstalk or other interference to SDA from SCL (or even other sources on the board).
I'm thinking that your GPS unit may not be responding due to noise interfering with the I2C address frame recognition in the MAX6G.
Given that the MAX6G is on the edge of the PCB, the traces to it may be more prone to induced noise interference on SDA and skew of SCL.
The addition of 50-100pF (or a scope probe load) would calm the noise/spikes on the line and reduce the potential for interference.

Have you tried reducing the I2C clock to say 50,000 and using the STD_DUTY_CYCLE?
I'm thinking you could readily increase your polling interval for power check (unless there is a very good reason for 100mS?)
You could then reduce the PuP values and with the lower polling rate, you would not increase average power consumption.

Anyway just some thoughts to chew on.

Cheers,

Bob

BTW - are you still putting these boards together using a crepe maker for BGA soldering?

[A319]

Hi everyone,

I just came back from Poland where I met some friends, who also build trackers. We have discussed about the I2C errors and we found the errors. We use two types: ublox MAX-6G and ublox MAX-7C or we thought...

The ublox MAX-7C was fake and is not performing like the original ones do. They are just crap.
The MAX-6G had other issues. It can only operate only up to 100kHz. But I operated at 150kHz. Like Bob advised, we reduced the I2C speed to 75kHz and it worked.

Apart from that, we still use sophistic barbecue techniques for baking our PCB's.

Regards Sven