On Tuesday 28 August 2018 16:49:16 Geoffrey Barton via mseide-msegui-talk wrote: > Hi Martin, > > I thought you might be interested to know that I successfully ran the > sample program for the STM32L100C by following the instructions in the txt > file from the mseuniverse/samples/embedded/arm folder.
Congrats! > It makes a very neat > dev system! > Thanks! :-) > I have also used mseide to compile, load and debug programs for an > STM32F446 after changing the cross compiler for the M4 and modifying the > project options accordingly. > > However, there is one odd thing which I hope you can help with. After > building the program it takes three sequences of target->continue before > the program successfully loads and runs. Specifically, the following is > observed:- > > (target->continue) > > util 1.5.0 > 2018-08-28T14:47:30 INFO common.c: Loading device parameters.... > 2018-08-28T14:47:30 INFO common.c: Device connected is: F446 device, id > 0x10006421 2018-08-28T14:47:30 INFO common.c: SRAM size: 0x20000 bytes (128 > KiB), Flash: 0x80000 bytes (512 KiB) in pages of 131072 bytes > 2018-08-28T14:47:30 INFO gdb-server.c: Chip ID is 00000421, Core ID is > 2ba01477. 2018-08-28T14:47:30 INFO gdb-server.c: Listening at *:4242... > 2018-08-28T14:47:32 INFO gdb-server.c: Found 6 hw breakpoint registers > 2018-08-28T14:47:32 INFO gdb-server.c: GDB connected. > 2018-08-28T14:47:34 INFO common.c: Attempting to write 16384 (0x4000) bytes > to stm32 address: 134217728 (0x8000000) Flash page at addr: 0x08000000 > erased > 2018-08-28T14:47:34 INFO common.c: Finished erasing 1 pages of 16384 > (0x4000) bytes 2018-08-28T14:47:34 INFO common.c: Starting Flash write for > F2/F4/L4 2018-08-28T14:47:34 INFO flash_loader.c: Successfully loaded flash > loader in sram enabling 32-bit flash writes > size: 16384 > 2018-08-28T14:47:35 INFO common.c: Starting verification of write complete > 2018-08-28T14:47:35 ERROR common.c: Verification of flash failed at offset: > 0 > Where do you see this listing? Does st-util download by itself or does gdb trigger the download? There is a delay setting in 'Project'-'Options'-'Debugger'-'Target'-'Wait before connect'. Maybe increase that value in order to make the time between starting st-util and connecting gdb bigger. The stm32l100c.prj example uses gdb for download. If download by gdb is not reliable disable 'Project'-'Options'-'Target'-'gdb download' and enter an appropriate download command in 'Download command'. > [...] > > If I send the commands too quickly in succession gdb can get into a state > where a hardware reset is the only way to resume communication. Which commands? Target-Continue? > I wonder > whether in general it is a timing issue eg. the write commands issued to > the stlink interface are sent too soon after the erase command (a 16k > sector erase takes 250->500 ms to execute), and then the debugger is > getting out of step. > Possible. MSEide uses the gdb-MI command -target-download for downloading if 'Project'-'Options'-'Target'-'gdb download' is set. > any suggestions? > You could try to download in standalone gdb in order to check if there is a problem in MSEide or in gdb <-> st-util. How behaves the MSEide command 'Target'-'Download'? Martin ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ mseide-msegui-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
