Closed Zacharyprime closed 2 years ago
Correction: it is stm32flash v0.4 on <=v26.1
Changelog from the authors of stm32flash:
stm32flash 0.7 was released 2022-03-26
Fix I2C page-by-page erase (Yann Sionneau)
Fix hex file base address not used, extraneous base padding (Renaud Fivet)
Fix truncated read from stdin (Renaud Fivet)
Fix input buffer flush on Windows (Jan Belohoubek)
More baud rates available, up to 4000000
Allow skipping serial port setup with -b 0
Support STM32L412xx/422xx (Andy Little)
Support STM32G05xxx/061xx (Luca Amati), STM32G0B0/B1/C1xx, STM32G491xx/A1xx
stm32flash 0.6 was released 2021-02-12
Many more devices supported G0/G4/F7/H7/L4 (various contributors)
GPIO sequencing reworked (Roman Savrulin)
Serial port handling improved (Mickael Gardet)
Many code improvements (Antonio Borneo)
Only erase needed pages if flashing from file (Tormod Volden)
stm32flash 0.5 was released 2016-02-11
support for multiple bank sizes
improved serial port support on Windows
improved erase functionality
improved hex parser
many new devices and device info corrections
Thanks to Antonio Borneo and many other contributors (see git log and AUTHORS file)
stm32flash 0.4 was released 2014-10-04 The 0.4 version is the work of Antonio Borneo and includes support for programming over I2C. See the included I2C.txt for more information. The code has been refactored to make it easier to add other transports.
I'm trying to get a hold of a copy of v0.4 to see if it will get better results. It seems to be an obscure version, maybe I can adjust the options of the new versions to get the same behavior
It turns out that the pins 8 and 10 (miniUART) are remapped to /dev/ttyS0 instead of /dev/ttyAMA0 if bluetooth is enabled.
That explains why it is disabled, but I am reusing the /boot/config.txt so that shouldn't effect the results I'm getting.
I tried switching "dtoverlay=pi3-disable-bt" to "dtoverlay=disable-bt" (matches what people are doing online). The results are the same. I don't know if there is a difference between the overlays other than maybe age.
I don't think this is related to the problem at this point. But as of writing this I'm not even sure where to look next. There must be a driver or bootstrapping process I didn't know about in the old images. The STM32 writes just fine with the old images and the same error occurs on different Wombats so it is likely not a hardware issue.
The main thing that sucks about this is that there is limited testing I can do when I can't test running programs due to DMA de-sync errors
Not sure what is happening here as disable-bt is a remapping (include) of pi3-disable-bt. Will look into the setup trace when I can get a chance to see why the mapping comes out different.
One thing you could try: in wallaby_flash change 'DEV=/dev/ttyAMA0' to 'DEV=/dev/ttyS0' In theory, that should work.
I saw comments saying to replace it with ttyS0 but I thought that it would require changing pins so I disregarded it.
I tried it but it just gave a failed to open error. However, while doing that I realized what the real problems were.
1) The GPIO direction wasn't being set to out before editing values. 2) The raspi-config had confusing wording. If you enable the login shell over serial, it disables the serial pins. But that option is under "interfacing" and is just called "serial port" which made me think I was enabling serial communication in general.
Thanks for the help!
There must be a driver that we are missing as part of the setup. I bet there was something modified to make it work back in development rather than something specific to jessie.
The error "unexpected reply" is not always the error, it also throws ACK errors, NACK errors, and "failed to init device". It seems to be random so it's possible there is something in the background of <=v26.1 that is activating the STM32.
I've tried using the installation that I saved in kipr-update and the one that is pulled from aptitude package manager. They are both v0.5 for me, and that would be the same as found on <=v26.1
I've tested it with two different Wombats so it is unlikely to be faulty hardware.