[MSEide-MSEgui-talk] arm embedded

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[MSEide-MSEgui-talk] arm embedded

mseide-msegui-talk mailing list
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. It makes a very neat dev system!

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


(target->continue)


util 1.5.0
2018-08-28T14:52:00 INFO common.c: Loading device parameters....
2018-08-28T14:52:00 INFO common.c: Device connected is: F446 device, id 0x10006421
2018-08-28T14:52:00 INFO common.c: SRAM size: 0x20000 bytes (128 KiB), Flash: 0x80000 bytes (512 KiB) in pages of 131072 bytes
2018-08-28T14:52:00 INFO gdb-server.c: Chip ID is 00000421, Core ID is  2ba01477.
2018-08-28T14:52:00 INFO gdb-server.c: Listening at *:4242...


(target->continue)


util 1.5.0
2018-08-28T14:53:31 INFO common.c: Loading device parameters....
2018-08-28T14:53:31 INFO common.c: Device connected is: F446 device, id 0x10006421
2018-08-28T14:53:31 INFO common.c: SRAM size: 0x20000 bytes (128 KiB), Flash: 0x80000 bytes (512 KiB) in pages of 131072 bytes
2018-08-28T14:53:31 INFO gdb-server.c: Chip ID is 00000421, Core ID is  2ba01477.
2018-08-28T14:53:31 INFO gdb-server.c: Listening at *:4242...
2018-08-28T14:53:34 INFO gdb-server.c: Found 6 hw breakpoint registers
2018-08-28T14:53:34 INFO gdb-server.c: GDB connected.
2018-08-28T14:53:35 INFO common.c: Attempting to write 16384 (0x4000) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2018-08-28T14:53:35 INFO common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2018-08-28T14:53:35 INFO common.c: Starting Flash write for F2/F4/L4
2018-08-28T14:53:35 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 16384
2018-08-28T14:53:36 INFO common.c: Starting verification of write complete
2018-08-28T14:53:36 INFO common.c: Flash written and verified! jolly good!



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.
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.

any suggestions?

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mse
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mse
Administrator
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mse
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mse
Administrator
On Tuesday 28 August 2018 18:43:45 Martin Schreiber wrote:
>
> 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



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mseide-msegui-talk mailing list
In reply to this post by mseide-msegui-talk mailing list


On 28 Aug 2018, at 22:15, [hidden email] wrote:

Send mseide-msegui-talk mailing list submissions to
[hidden email]

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
[hidden email]

You can reach the person managing the list at
[hidden email]

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 <[hidden email]>
Subject: Re: [MSEide-MSEgui-talk] arm embedded
Date: 28 August 2018 at 17:43:45 BST


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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mse
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mse
Administrator
On Wednesday 29 August 2018 15:46:24 Geoffrey Barton via mseide-msegui-talk
wrote:
> > 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?
>
I assume that st-util should do the necessary steps to flash the chip. Is
flashing with standalone st-util reliable? Does a manual 'Target'-'Reset' in
MSEide change the situation?

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mseide-msegui-talk mailing list


> On 29 Aug 2018, at 15:19, Martin Schreiber <[hidden email]> wrote:
>
> On Wednesday 29 August 2018 15:46:24 Geoffrey Barton via mseide-msegui-talk
> wrote:
>>> 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?
>>
> I assume that st-util should do the necessary steps to flash the chip. Is
> flashing with standalone st-util reliable?

I have not tried it since I have had the download problem, but I will.

> Does a manual 'Target'-'Reset' in
> MSEide change the situation?

No, I think because, if indeed the Target-Reset triggers a hardware reset, the processor then immediately boots from flash and runs again.

I have now added a ‘while’ loop waiting for an external processor port to be pulled low just before the main code configures and enables the data i/o interrupts.

The ‘Target’->’continue’  downloads without error every time, the main code (and interrupts) then only run after you press a push button connected to the port.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mse
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mse
Administrator
On Wednesday 29 August 2018 16:54:03 Geoffrey Barton via mseide-msegui-talk
wrote:
>
> > Does a manual 'Target'-'Reset' in
> > MSEide change the situation?
>
> No, I think because, if indeed the Target-Reset triggers a hardware reset,
> the processor then immediately boots from flash and runs again.
>
Does a MSEide 'Target'-'Interrupt' actually stop the target?
AFAIK running st-util without the -n parameter resets the board. MSEide should
restart st-util before downloading or after a reset.
Is there a difference in downloading the first time after MSEide start?

The tutorial
https://github.com/texane/stlink/blob/master/doc/tutorial.md
writes about connecting the target by "(gdb) target extended localhost:4242".
You could try to change 'Project'-'Options'-'Debugger'-'Target'-'Target
connection' to "extended localhost:4242".

There is a stlink bugtracker in case you find a problem in st-util:
https://github.com/texane/stlink/issues

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mse
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mse
Administrator
In reply to this post by mseide-msegui-talk mailing list
On 08/28/2018 04:49 PM, Geoffrey Barton via mseide-msegui-talk wrote:

>
> 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:-
>
[...]
MSEide git master 9823ee0cca445eeb551c1172aaecb1fe2ac10a1a has
'Project'-'Options'-'Debugger'-'Target'-'Restart gdb before load'
(experimental), maybe it helps.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mseide-msegui-talk mailing list
In reply to this post by mse


> On 29 Aug 2018, at 17:23, Martin Schreiber <[hidden email]> wrote:
>
> On Wednesday 29 August 2018 16:54:03 Geoffrey Barton via mseide-msegui-talk
> wrote:
>>
>>> Does a manual 'Target'-'Reset' in
>>> MSEide change the situation?
>>
>> No, I think because, if indeed the Target-Reset triggers a hardware reset,
>> the processor then immediately boots from flash and runs again.
>>
> Does a MSEide ‘Target'-'Interrupt' actually stop the target?

yes, but the dma still runs; it just loops the chunk of data it has in its output buffer a few milliseconds long, so it must be still accessing ram.

> AFAIK running st-util without the -n parameter resets the board. MSEide should
> restart st-util before downloading or after a reset.
> Is there a difference in downloading the first time after MSEide start?

I think so, I will have to remove the push button check to find out.

>
> The tutorial
> https://github.com/texane/stlink/blob/master/doc/tutorial.md
> writes about connecting the target by "(gdb) target extended localhost:4242".
> You could try to change 'Project'-'Options'-'Debugger'-'Target'-'Target
> connection’ to "extended localhost:4242".

I will try that too later.
thanks,

Geoffrey

>
> There is a stlink bugtracker in case you find a problem in st-util:
> https://github.com/texane/stlink/issues
>
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mseide-msegui-talk mailing list
In reply to this post by mse


> On 30 Aug 2018, at 15:43, Martin Schreiber <[hidden email]> wrote:
>
> On 08/28/2018 04:49 PM, Geoffrey Barton via mseide-msegui-talk wrote:
>
>>
>> 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:-
>>
> [...]
> MSEide git master 9823ee0cca445eeb551c1172aaecb1fe2ac10a1a has
> 'Project'-'Options'-'Debugger'-'Target'-'Restart gdb before load'
> (experimental), maybe it helps.

Ok. Am trying to build it now. It seems that ‘Xlib’ is missing.

Geoffrey

>
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mse
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mse
Administrator
On 08/30/2018 05:29 PM, Geoffrey Barton via mseide-msegui-talk wrote:

>
>
>> On 30 Aug 2018, at 15:43, Martin Schreiber <[hidden email]> wrote:
>>
>> On 08/28/2018 04:49 PM, Geoffrey Barton via mseide-msegui-talk wrote:
>>
>>>
>>> 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:-
>>>
>> [...]
>> MSEide git master 9823ee0cca445eeb551c1172aaecb1fe2ac10a1a has
>> 'Project'-'Options'-'Debugger'-'Target'-'Restart gdb before load'
>> (experimental), maybe it helps.
>
> Ok. Am trying to build it now. It seems that ‘Xlib’ is missing.
>
The X11-devel package is needed. Please see
https://bugs.freepascal.org/view.php?id=32367
about the background.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mseide-msegui-talk mailing list


> On 30 Aug 2018, at 17:16, Martin Schreiber <[hidden email]> wrote:
>
> On 08/30/2018 05:29 PM, Geoffrey Barton via mseide-msegui-talk wrote:
>>
>>
>>> On 30 Aug 2018, at 15:43, Martin Schreiber <[hidden email]> wrote:
>>>
>>> On 08/28/2018 04:49 PM, Geoffrey Barton via mseide-msegui-talk wrote:
>>>
>>>>
>>>> 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:-
>>>>
>>> [...]
>>> MSEide git master 9823ee0cca445eeb551c1172aaecb1fe2ac10a1a has
>>> 'Project'-'Options'-'Debugger'-'Target'-'Restart gdb before load'
>>> (experimental), maybe it helps.
>>
>> Ok. Am trying to build it now. It seems that ‘Xlib’ is missing.
>>
> The X11-devel package is needed. Please see
> https://bugs.freepascal.org/view.php?id=32367
> about the background.

It is already installed.

But I found the {MSEDIR} was wrong as this is not set by the project file but by ‘settings’ ‘configure mseide’ and it was not pointing at the git version.
After correcting this it now fails at:-


msesysintf1.pas(69,2) Fatal: Can't find unit dateutils used by msesysintf1

I take this to be the FPC dateutils, which appears to be present and correct.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mse
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mse
Administrator
On 08/30/2018 07:04 PM, Geoffrey Barton via mseide-msegui-talk wrote:
>
>
> msesysintf1.pas(69,2) Fatal: Can't find unit dateutils used by msesysintf1
>
> I take this to be the FPC dateutils, which appears to be present and correct.
>
Is the .fpc.cfg OK? It is possible to compile MSEide from the commandline by
"
fpc -Fulib/common/* -Fulib/common/kernel/linux apps/ide/mseide.pas
"
in git clone directory.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mseide-msegui-talk mailing list


> On 30 Aug 2018, at 18:37, Martin Schreiber <[hidden email]> wrote:
>
> On 08/30/2018 07:04 PM, Geoffrey Barton via mseide-msegui-talk wrote:
>>
>>
>> msesysintf1.pas(69,2) Fatal: Can't find unit dateutils used by msesysintf1
>>
>> I take this to be the FPC dateutils, which appears to be present and correct.
>>
> Is the .fpc.cfg OK? It is possible to compile MSEide from the commandline by
> "
> fpc -Fulib/common/* -Fulib/common/kernel/linux apps/ide/mseide.pas
> "
> in git clone directory.

Good call.I checked fpc.cfg and it is ok, but the folder to which it points for the compiled units has had its name changed, presumably by something else I have installed.
Can now compile ok.


> MSEide git master 9823ee0cca445eeb551c1172aaecb1fe2ac10a1a has
> 'Project'-'Options'-'Debugger'-'Target'-'Restart gdb before load'
> (experimental), maybe it helps.

Unfortunately does not seem any different!

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mse
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mse
Administrator
On Friday 31 August 2018 11:37:40 Geoffrey Barton via mseide-msegui-talk
wrote:
>
> Unfortunately does not seem any different!
>
I could reproduce with a ST discovery board that 'Target'-'Download' every
second time failed with a 'Remote connection closed' error. By
activating 'Restart gdb before load' 'Target'-'Download' works every time for
me.
I assume there is an another problem with the running DMA on your board.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mseide-msegui-talk mailing list


> On 31 Aug 2018, at 11:00, Martin Schreiber <[hidden email]> wrote:
>
> On Friday 31 August 2018 11:37:40 Geoffrey Barton via mseide-msegui-talk
> wrote:
>>
>> Unfortunately does not seem any different!
>>
> I could reproduce with a ST discovery board that 'Target'-'Download' every
> second time failed with a 'Remote connection closed' error. By
> activating 'Restart gdb before load' 'Target'-'Download' works every time for
> me.

try ‘project’ ‘build’ before download each time. This shows the one in three success rate here.

Just repeating ’target’ ‘download’ has a one in two success rate (with ‘restart gdb before load’ selected).


> I assume there is an another problem with the running DMA on your board.

yes, its odd that, now you have replicated the problem. Here, if I disable the i2s/dma connection,  ‘project’ ‘build’ followed by ’target’ ‘continue’ works every time!
Is your disco board an M3 or M4? I am using the M4 (and the processor pulldown is set at armm3). I have not traced the function of the pulldown; I assume it is just to do with register names.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mse
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mse
Administrator
On Friday 31 August 2018 12:22:29 Geoffrey Barton via mseide-msegui-talk
wrote:

> > On 31 Aug 2018, at 11:00, Martin Schreiber <[hidden email]> wrote:
> >
> > On Friday 31 August 2018 11:37:40 Geoffrey Barton via mseide-msegui-talk
> >
> > wrote:
> >> Unfortunately does not seem any different!
> >
> > I could reproduce with a ST discovery board that 'Target'-'Download'
> > every second time failed with a 'Remote connection closed' error. By
> > activating 'Restart gdb before load' 'Target'-'Download' works every time
> > for me.
>
> try ‘project’ ‘build’ before download each time. This shows the one in
> three success rate here.
>
That works every time for me independent of the setting of 'Restart gdb before
load'.

> Just repeating ’target’ ‘download’ has a one in two success rate (with
> ‘restart gdb before load’ selected).
>
Which error message in MSEide status display?

> > I assume there is an another problem with the running DMA on your board.
>
> yes, its odd that, now you have replicated the problem. Here, if I disable
> the i2s/dma connection,  ‘project’ ‘build’ followed by ’target’ ‘continue’
> works every time! Is your disco board an M3 or M4?

M3.

> I am using the M4 (and
> the processor pulldown is set at armm3). I have not traced the function of
> the pulldown; I assume it is just to do with register names.
>
Correct, it switches the displayed CPU form.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mseide-msegui-talk mailing list


> On 31 Aug 2018, at 12:45, Martin Schreiber <[hidden email]> wrote:
>
> On Friday 31 August 2018 12:22:29 Geoffrey Barton via mseide-msegui-talk
> wrote:
>>> On 31 Aug 2018, at 11:00, Martin Schreiber <[hidden email]> wrote:
>>>
>>> On Friday 31 August 2018 11:37:40 Geoffrey Barton via mseide-msegui-talk
>>>
>>> wrote:
>>>> Unfortunately does not seem any different!
>>>
>>> I could reproduce with a ST discovery board that 'Target'-'Download'
>>> every second time failed with a 'Remote connection closed' error. By
>>> activating 'Restart gdb before load' 'Target'-'Download' works every time
>>> for me.
>>
>> try ‘project’ ‘build’ before download each time. This shows the one in
>> three success rate here.
>>
> That works every time for me independent of the setting of 'Restart gdb before
> load'.
>
>> Just repeating ’target’ ‘download’ has a one in two success rate (with
>> ‘restart gdb before load’ selected).
>>
> Which error message in MSEide status display?

“GDB: Error finishing flash operation”

>
>>> I assume there is an another problem with the running DMA on your board.
>>
>> yes, its odd that, now you have replicated the problem. Here, if I disable
>> the i2s/dma connection,  ‘project’ ‘build’ followed by ’target’ ‘continue’
>> works every time! Is your disco board an M3 or M4?
>
> M3.
>
>> I am using the M4 (and
>> the processor pulldown is set at armm3). I have not traced the function of
>> the pulldown; I assume it is just to do with register names.
>>
> Correct, it switches the displayed CPU form.

so the only difference between gdb on your disco M3 and my nucleo M4 is the i2s/DMA being driven and anything in stlink which is different for M3 vs M4.

Geoffrey

>
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mse
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mse
Administrator
On Friday 31 August 2018 16:13:35 Geoffrey Barton via mseide-msegui-talk
wrote:
> >> Just repeating ’target’ ‘download’ has a one in two success rate (with
> >> ‘restart gdb before load’ selected).
> >
> > Which error message in MSEide status display?
>
> “GDB: Error finishing flash operation”
>
Which is probably the running DMA problem and not the 'Remote connection
closed' I got.

[...]
>
> so the only difference between gdb on your disco M3 and my nucleo M4 is the
> i2s/DMA being driven and anything in stlink which is different for M3 vs
> M4.
>
Yes. The question is how can MSEide reliably stop the DMA and all other
actions in the target board before downloading. Shouldn't that be done by
st-util/stlink?

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mse
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] arm embedded

mse
Administrator
On Friday 31 August 2018 16:33:24 Martin Schreiber wrote:
>
> Yes. The question is how can MSEide reliably stop the DMA and all other
> actions in the target board before downloading. Shouldn't that be done by
> st-util/stlink?
>
I assume the the DBGMCU register flags must be set accordingly by one way or
another. You could try with a 'Target'-'Options'-'Debugger'-'Target'-'After
connect gdb script'. Maybe it is too late then and the setting must be done
by stlink.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
12