Activity for Yann Sionneau
-
Yann Sionneau posted a comment on ticket #131
I am dropping by just to say that ST released a new version of AN4221 where bootloader v1.2 is "documented" https://www.st.com/resource/en/application_note/an4221-i2c-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf
-
I would be in favor of integrating this patch, we use it as a local patch and so far it works great to flash our stm32f723.
-
I think our ST tools (stflash) use stlink probe which itself I am guessing is using JTAG. With another tool (dfu util) we use stm32's bootloader USB DFU function.
-
This patch looks good to me :)
-
Hello Tormod, About your v2, I prefer my version because I make it explicit about the "10 ms steps". For instance with the v2 patch if I do "-t 9" I get 0 timeout. If I do "-t 19" I get 10 ms. Or maybe round it to superior bound?
-
Hello, I've asked the question on ST forum: https://community.st.com/s/question/0D53W00001BTueOSAT/stm32f723-i2c-bootloader-nostretch-erase-command-leads-to-long-clock-stretching-anyway-how-to-deal-with-it
-
What can I do to make this patch progress forward?
-
I replaced the sleep(10) with sleep(1) and I don't get the NACK anymore, I am back to the timeout due to clock being stretched a very long time. Now I get : Write FF FF 00 ; 1 second idle on the I2C lines (logical level 1) ; then the master tries to issue a Read, but the ACK bit is clock stretched (like the original issue). Then I end up seeing 0x76 on the lines but it's too late, the master abandoned because of a timeout in the Linux driver stack. btw 0x76 seems to mean "BUSY" so I get both a big...
-
I added a sleep(10) (since I get approx' 7 seconds of clock stretching usually) in stm32_mass_erase() between the write of FF FF 00 and the call to stm32_get_ack_timeout() The result I get on the lines is that the stm32_get_ack_timeout() is NACKed. Meaning I see a long "pause" during which no I2C activity, and then I can see a Read issues to address 0x4D, the I2C address is NACK'ed. And the whole operation fails.
-
Only reference I have on bootloader v1.2 is: https://community.st.com/s/question/0D53W00000bfOip/stm32g030f6-i2c-bootloader-v12
-
Here are zoomed-in pictures of the analyzer I honestly don't know what the bootloader is doing since I don't have its source code :/ I also don't have the spec of v1.2, just like you indeed I can only check that in the spec only 1.0 and 1.1 are specified... :/ If you have friends at STmicro, maybe it's the time to ask them :p
-
Here are zoomed-in pictures of the analyzer I honestly don't know what the bootloader is doing since I don't have its source code :/ I also don't have the spec of v1.2, just like you indeed I can only check that in the spec only 1.0 and 1.1 are specified... :/
-
Here are zoomed-in pictures of the analyzer
-
It is a bit of mystery to me also. I can confirm that without the "-t timeout" patch, I get this behaviour: stm32flash -w flashdump -v -g 0x0 -a 0x4d /dev/i2c-1 stm32flash 0.6 http://stm32flash.sourceforge.net/ Using Parser : Raw BINARY Size : 524288 Warning: Not a tty: /dev/i2c-1 Error probing interface "serial_posix" Interface i2c: addr 0x4d Version : 0x12 Device ID : 0x0452 (STM32F72xxx/73xxx) - RAM : Up to 256KiB (16384b reserved by bootloader) - Flash : Up to 512KiB (size first sector: 1x16384)...
-
It is a bit of mystery to me also. I can confirm that without the "-t timeout" patch, I get this behaviour: stm32flash -w flashdump -v -g 0x0 -a 0x4d /dev/i2c-1 stm32flash 0.6 http://stm32flash.sourceforge.net/ Using Parser : Raw BINARY Size : 524288 Warning: Not a tty: /dev/i2c-1 Error probing interface "serial_posix" Interface i2c: addr 0x4d Version : 0x12 Device ID : 0x0452 (STM32F72xxx/73xxx) - RAM : Up to 256KiB (16384b reserved by bootloader) - Flash : Up to 512KiB (size first sector: 1x16384)...
-
It is a bit of mystery to me also. I can confirm that without the "-t timeout" patch, I get this behaviour: stm32flash -w flashdump -v -g 0x0 -a 0x4d /dev/i2c-1 stm32flash 0.6 http://stm32flash.sourceforge.net/ Using Parser : Raw BINARY Size : 524288 Warning: Not a tty: /dev/i2c-1 Error probing interface "serial_posix" Interface i2c: addr 0x4d Version : 0x12 Device ID : 0x0452 (STM32F72xxx/73xxx) - RAM : Up to 256KiB (16384b reserved by bootloader) - Flash : Up to 512KiB (size first sector: 1x16384)...
-
I can confirm that using upstream stm32flash (+ the -t timeout patch) it works to flash my stm32. So the already merged patch about the i2c protocol is OK! Thanks!
-
Hello, I would need to find time to have a look again at what happens exactly. I will do that in the next ~30 days like for ticket 98. In my case when the master times out I need to reboot the board. After the timeout, the i2c Linux bus (/dev/i2c-XX) is un-usable/dead.
-
Thanks for the feedback and the merge! I will try to find some time in the next ~30 days or so to test that it works. AFAIK I really need to be able to increase the timeout of the i2c master driver (about the -t patch in ticket 131). Let's see when I find the time to test again :)
-
Here is the patch. I made special care not to break USART but I don't have the hw for testing. What I have tested: * it works well for mass-erase and page-by-page erase over I2C with STM32F723 (it was not working before) What I didn't test and should be tested before merging: * That USART flash isn't broken by the patch Anyone motivated to test the patch for USART use case? :) PS : patch is done for being applied after this one: https://sourceforge.net/p/stm32flash/tickets/131/#e8d8
-
Here is the patch. What I have tested: * it works well for mass-erase and page-by-page erase over I2C with STM32F723 (it was not working before) What I didn't test and should be tested before merging: * That USART flash isn't broken by the patch Anyone motivated to test the patch for USART use case? :) PS : patch is done for being applied after this one: https://sourceforge.net/p/stm32flash/tickets/131/#e8d8
-
Here is the patch. What I have tested: * it works well for mass-erase and page-by-page erase over I2C with STM32F723 (it was not working before) What I didn't test and should be tested before merging: * That USART flash isn't broken by the patch Anyone motivated to test the patch for USART use case? :)
-
A new version of the patch, with an helpful error message.
-
Hello, I can confirm the I2C bootload protocol implemented is incorrect for erase comands. I have a fix, but it breaks USART since I didn't know that the current one was the good one for USART. I'm working on a solution which works for both. I don't have any setup to test I don't break USART case but if someone will be willing to test... I'll keep you posted as soon as I have a correct fix.
-
[patch] add -t command line option to specify i2c communication timeout
1
