> On 28 Aug 2018, at 22:15, [email protected]
> wrote:
>
> Send mseide-msegui-talk mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of mseide-msegui-talk digest..."
> Today's Topics:
>
> 1. Re: arm embedded (Martin Schreiber)
> 2. Re: arm embedded (Martin Schreiber)
> 3. Re: a little benchmark (msegui lazarus wxwidgets) (code dz)
>
> From: Martin Schreiber <[email protected]>
> Subject: Re: [MSEide-MSEgui-talk] arm embedded
> Date: 28 August 2018 at 17:43:45 BST
> To: [email protected]
>
>
> 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?
This is in the terminal window used to start mseide
> Does st-util download by itself or does gdb
> trigger the download?
The setup is as your L100C example.
> 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.
this just makes it take longer before the problem happens.
> 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?
yes. The listing above consists of the commands (Target->continue) interleaved
with the screen snippets which are from the message window of mseide and the
text from the terminal window. It certainly does not display well on the digest.
>
>> 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'?
has the same problem as ‘continue’, every third one fails.
>
>>
>> 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'?
>>
> I saw your screen snippes only now, it seems clear that there is a problem
> with gdb downloading. Such things are difficult to debug.
>
> Martin
>
I have just found that, if I power down the external data connections to the
nucleo board, which are an i2s via DMA, the ’target->continue’ command works
every time.
It appears as though perhaps the DMA is still running when the debugger is
supposed to be in control and there is some conflict.
Does the debugger reset and stop the processor running before it erases the
flash and downloads?
Geoffrey
------------------------------------------------------------------------------
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
