Monday, February 19th 2018, 2:41am UTC+1

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

br.bytec

Beginner

Date of registration: Mar 27th 2013

Posts: 5

1

Thursday, March 28th 2013, 9:58am

Debugging and flashing fails with CodeSourcery

I am trying to flash an debug an STM32F205 MCU using J-link and Codesourcery 2012.09-85.
I have tried several version of J-link software, including the latest one (4.66).
The JFlasher can read and flash the MCU just fine, but flashing and debugging does not work from CodeSourcery.

I keep getting error messages:

---
-target-download C:/src/sandbox/Ruck/Lisa/MCU/D322_00/Lisa_Debug_HP/D336_00
Error message from debugger back end:
Error erasing flash with vFlashErase packet
---

Also the debugger seems to be unable to read back data from ROM or RAM.

This is the same with a STM3220G evel board and our own boards.
I don't think it is a hardware problem as most of the boards have been successfully debugged before using an older version of CodeSourery.

Any ideas?

SEGGER - Rolf

Super Moderator

Date of registration: Nov 21st 2007

Posts: 65

2

Saturday, March 30th 2013, 7:01pm

This sounds as if Codesourcery had changed their GDB interface.
Normally, the vErase packet should not be sent (It should only be sent if the GDBServer reports that it can handle this packet).
Since J-Link handles Erase automatically, there is no need to handle this packet, and it should not be sent.

In any case, we will look into this and either modify the J-Link GDBServer or get in touch with CodeSourcery (Mentor) asking them
to fix it, assuming that we can reproduce it.
Until then, it seems an easy workaround is to use an older version of CodeSourcery, especially as you write
that an older version of this stuff works:

Quoted

I don't think it is a hardware problem as most of the boards have been successfully debugged before using an older version of CodeSourery.


Which older version are you using that works and can you verify it also works with the STM32F205?
J-Link can handle that device.

SEGGER - Alex

Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,516

3

Tuesday, April 2nd 2013, 2:12pm

Hi,

Could you please share some more information about how you use J-Link from within CodeSourcery?
Do you use it directly (by selecting J-Link in CodeSourcery)?
Or do you select "GDB" as debugging interface and explicitly start J-Link GDBServer and let CodeSourcery connect to it?

I assume that you use J-Link directly. If this is the case, there is not much we can fix here since CodeSourcery communicates
with the J-Link DLL directly and performs some CodeSourcery-internal GDB <-> J-Link mapping, so we do not even get this "vFlashErase" packet.


Best regards
Alex

br.bytec

Beginner

Date of registration: Mar 27th 2013

Posts: 5

4

Thursday, April 4th 2013, 9:50am

Hi Alex,

thanks for your reply.

The version that had worked previously was: 2011.09-82
I tested it successfully with an STM32F207 (did not have a 'F205 at the time), after updating the DLL to version 4.56d, as the version included in codesourcery (4.42b) did not support the 'F207.

You assume correctly that we are using J-ling directly from within CodeSourcery.

I have received a modified version of the Debug sprite, but it did not fix the problem. A attach a debug log file, maybe you can find something there.

The log window of the JLink interface seems to show no problem. Is there a way to save an attach that log, too?

Thanks
Bernhard
br.bytec has attached the following file:
  • debug-console.txt (52.37 kB - 679 times downloaded - Last download: Yesterday, 4:09am)

SEGGER - Alex

Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,516

5

Thursday, April 4th 2013, 10:27am

Hi Bernhard,

Quoted

A attach a debug log file, maybe you can find something there.

As far as I understand it, it looks good.
I do not even see any errors regarding "vFlashErase" being reported there.

Quoted

The log window of the JLink interface seems to show no problem. Is there a way to save an attach that log, too?

Could you please specify what you mean here?
In general, a J-Link log file can be created by opening the control panel (just click the small J-Link tray icon in the bottom right corner which shows up as soon as the debug session is started)
and select "Override" for the logfile in the "Settings" tab.
Then just re-start the debug session to get a complete log from the beginning.


Best regards
Alex

br.bytec

Beginner

Date of registration: Mar 27th 2013

Posts: 5

6

Tuesday, April 9th 2013, 10:16am

Alex,

I have tried some more here. I found the using the "STM32F207IG" as an MCU type in the board file (code sourcery), flashing does indeed work fine. Changing the chip to "STM32F204ZF" (which is actually used on our board), flashing no longer works. Both chips are set to use 768k of flash.

This is the version info from the GDB server:

EGGER J-Link GDB Server V4.56d
JLinkARM.dll V4.56d (DLL compiled Nov 12 2012 20:40:34)


Next problem after flashing is this:
I can see the program start at the beginning of "main()" function. I can also step over other functions called by main().
However when I set a breakpoint and run the application, it does not correctly stop at the breakpoint as expected.

Instead the IDE shows an incomplete stack trace:

Thread [1] <main> (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)
0x0
0x0

Also there is an error message about being unable to registers while the MCU is running (which is probably the cause for the invalid stack)

I attach the log window output of the segger GDB server. Maybe you can see something from it?
br.bytec has attached the following file:

br.bytec

Beginner

Date of registration: Mar 27th 2013

Posts: 5

7

Tuesday, April 9th 2013, 10:28am

I also tried the GDB server (JTAG) from version 4.66a.

Result is the same: after a couple of single step operations, the bad stack appears. Log file from GDB server is attached.segger-gbd-server-4.66a.txt