Failed to launch gdb error erasing flash with vflasherase packet from target download

Failed to launch gdb error erasing flash with vflasherase packet from target download The Debugging host is a RPi 4, the target is a RP2040. I followed all of the Debug Setup guidance documented in «https://datasheets.raspberrypi.org/pico . h-pico.pdf». The command line debug test using two terminals, one running openocd and the other gdb_multiarch works. […]

Содержание

  1. Failed to launch gdb error erasing flash with vflasherase packet from target download
  2. Re: VS Code PICO Debugging from RPi4 does not work
  3. Re: VS Code PICO Debugging from RPi4 does not work
  4. Failed to launch gdb error erasing flash with vflasherase packet from target download
  5. Re: VS Code PICO Debugging from RPi4 does not work
  6. Re: VS Code PICO Debugging from RPi4 does not work
  7. STM32F76x Error erasing flash with vFlashErase packet #365
  8. Comments
  9. Failed to launch gdb error erasing flash with vflasherase packet from target download
  10. Re: Having some problems with picoprobe/openOCD/GDB
  11. Re: Having some problems with picoprobe/openOCD/GDB
  12. Re: Having some problems with picoprobe/openOCD/GDB
  13. Re: Having some problems with picoprobe/openOCD/GDB
  14. Re: Having some problems with picoprobe/openOCD/GDB
  15. Re: Having some problems with picoprobe/openOCD/GDB
  16. Re: Having some problems with picoprobe/openOCD/GDB
  17. Re: Having some problems with picoprobe/openOCD/GDB
  18. Failed to launch gdb error erasing flash with vflasherase packet from target download
  19. Re: Picoprobing a Pico on a different voltage source: errors sending code over
  20. Re: Picoprobing a Pico on a different voltage source: errors sending code over

Failed to launch gdb error erasing flash with vflasherase packet from target download

The Debugging host is a RPi 4, the target is a RP2040. I followed all of the Debug Setup guidance documented in «https://datasheets.raspberrypi.org/pico . h-pico.pdf». The command line debug test using two terminals, one running openocd and the other gdb_multiarch works.

It does not work from VS Code. Code executes CMake and Make properly then when it launches the openOCD logic it always fails.
The error displayed is «Failed to launch GDB: Error erasing flash with vFlashErase packet (from target-download)»

I can’t be the only to have encountered this issue.

I have included CS Code Adapter Output:
— openocd log —

Re: VS Code PICO Debugging from RPi4 does not work

You might be — the Pico is that new.

FWIW, my Pi4 loves debugging my Pico, so yes, it does work.

Have you used the shortest wires you can — 10 or 15cm?

PS, for large globs of log, please format them in to a code block as it does automagically scrolling and reduces the post size — if you can, please edit your post to add it. Ta

Re: VS Code PICO Debugging from RPi4 does not work

I am using short wires between Pico and RPi4.
Using GDB command line interface will load and debug the program properly.
In GDB, I use the «file» command to load the ELF file.
The issue I am having is specific to «code» using the «flash» command.
Is there a configuration that uses the «file» command in place of «flash»?
Does this question make sense?

Источник

Failed to launch gdb error erasing flash with vflasherase packet from target download

The Debugging host is a RPi 4, the target is a RP2040. I followed all of the Debug Setup guidance documented in «https://datasheets.raspberrypi.org/pico . h-pico.pdf». The command line debug test using two terminals, one running openocd and the other gdb_multiarch works.

It does not work from VS Code. Code executes CMake and Make properly then when it launches the openOCD logic it always fails.
The error displayed is «Failed to launch GDB: Error erasing flash with vFlashErase packet (from target-download)»

I can’t be the only to have encountered this issue.

I have included CS Code Adapter Output:
— openocd log —

Re: VS Code PICO Debugging from RPi4 does not work

You might be — the Pico is that new.

FWIW, my Pi4 loves debugging my Pico, so yes, it does work.

Have you used the shortest wires you can — 10 or 15cm?

PS, for large globs of log, please format them in to a code block as it does automagically scrolling and reduces the post size — if you can, please edit your post to add it. Ta

Re: VS Code PICO Debugging from RPi4 does not work

I am using short wires between Pico and RPi4.
Using GDB command line interface will load and debug the program properly.
In GDB, I use the «file» command to load the ELF file.
The issue I am having is specific to «code» using the «flash» command.
Is there a configuration that uses the «file» command in place of «flash»?
Does this question make sense?

Источник

STM32F76x Error erasing flash with vFlashErase packet #365

Hi, I’m trying to debug a STM32F765 but it fails to load with Error erasing flash with vFlashErase packet
I’m using an stlink clone with firmware updated just now from: http://builds.blacksphere.co.nz/blackmagic
If it helps, current head is at d4d24c2

I previously had issues flashing with this part with a segger, the dual bank flash seemed to trip it up. Is it likely something similar here?

The text was updated successfully, but these errors were encountered:

Check the device option bits. Erase option bits and check again. If there is a differences,perhaps you accidental write protected the flash. Mass erase the device. Does that work? Can you flash after option and flash mass erase? If second flash does not work, check your programm that is does not do anything strange.

As a test I switched to a different stlink converted to segger jlink and that works fine, no mass erase needed.

Please post the output of arm-none-eabi-size -x -A *elf

I could try to flash your elf file to a nucleo-f767 if you make it available.

I can share it tomorrow when I’m back in the office however it’s based on this so should be completely compatible with the elf here:

I haven’t tried flashing the elf directly from these guys though.

I just double checked and yes, firmware.elf from the above git repo does have the same error for me.
jlink with the same elf works fine.

Will check with a F767 a.s.a.p.

Please test #366. Fixes obvious omission and fixxes the problem for me

That looks great thanks. I’ll test in when I’m back in the office in around 12 hours.

Yes, I can confirm this does fix the problem, thanks!

I’ve seen this a few times on a couple of different STM32 systems.
What I’ve found is that the debugger NRST is not working. I have no idea why, everything is connected correctly and the NRST pin is not being held by an external device. The only solution is to go into the debugger setup and switch to «Software system reset». Then you don’t even need the reset line.

Источник

Failed to launch gdb error erasing flash with vflasherase packet from target download

If I load the «release» binary via the USB .uf2 file, then it works just fine.

I tried a brand new target pico, and a brand new picoprobe, but the problem persists.

Since I was using VisualGDB in Windows 10, I thought it would be prudent to try the same thing with an rPi4 VisualStudioCode environment. I managed to get that all set up, but still encounter problems trying to debug the blink example. The output of that looks like..

So now I’m at a total loss of what to try next. Both development platforms fail with new picos for target and picoprobe where it had been working just fine for a few months with the VisualGDB setup.

Re: Having some problems with picoprobe/openOCD/GDB

Re: Having some problems with picoprobe/openOCD/GDB

I’m having the DAP Init failure too. If I juggle USB ports several times and restart VS code, I can usually get it to start working for that session. But if I turn off my breadboard and laptop and come back the next day, 100% of the time it doesn’t work on the first shot. OpenOCD failed to start / DAP init error.

Would love to find a way to make this more reliable. I already soldered up a nice and short cable to connect the 2 picos but it didn’t seem to help over just using loose Dupont wires.

Re: Having some problems with picoprobe/openOCD/GDB

As I said in OP, I’m working with two development platforms. Windows MS Visual Studio 2019 Community Edition with VisualGDB, and also rPi4 with VSCode.

In both cases, I can never successfully start a debug session on the first attempt. Mostly it works on the second attempt in Windows, but might take a few more tries on the rPi4 VSCode. I don’t re-compile on the Windows platform, and have selected the option to program flash only when binary changed. I think that the VSCode always re-compiles, and programs the flash — but I’m not too familiar with this environment, so I might be mistaken.

Typically, the symptom is that I hit a hard fault exception in crt; sometime it just goes to never-never land, and I have to manually stop debug.

On VSCode, I captured the GDB log when it failed.

Re: Having some problems with picoprobe/openOCD/GDB

Re: Having some problems with picoprobe/openOCD/GDB

Re: Having some problems with picoprobe/openOCD/GDB

Re: Having some problems with picoprobe/openOCD/GDB

Re: Having some problems with picoprobe/openOCD/GDB

Well, that didn’t make a difference. But, I’m starting to notice something: I think the new macs (or MY new mac) and newest OSX are «weird» about USB ports. I can’t figure out what it is, but I have a couple of other hardware items that act weird:

1) Plugging my Android phone in to use Android File Transfer app, I have to plug and unplug several times to get it to enumerate and launch the app. Switching to a different USB port will usually work faster though.

2) A USB to MIDI converter will sometimes not work on first plug in. Swapping it to another port will make it work. If I come back the next day on a fresh reboot say, the device will work on the other port.

It’s like there’s some kind of handshaking/checking happening in the background when you plug USB items into these new macs and sometimes it just doesn’t work, but doesn’t show an error.

Источник

Failed to launch gdb error erasing flash with vflasherase packet from target download

Hi all; skip to tl;dr to see issue + current status

Currently trying to debug a Pico hooked up to a separate voltage source (3xAA) whilst the probe is hooked up to the usual mUSB. I’ve got the leads going into the castellations soldered up appropriately as in the usual tutorials (leaving the ground of the 3-pin debug header unsoldered on the slave to the probe, as everyone does. If someone suggests soldering this too, I have to note that the grounds of the slave and the probe are different- the former is battery powered.)

Trying to use the usual debug facility over the Probe through Visual Studio Code I’m getting errors, ex.

See the 2nd reply (my first reply) to this post for an update. tl;dr is that I’ve tried resoldering the setup/etc, and it won’t work. I know the probe works- it’s had months of use on a perfboard version of this exact project (which I have now migrated to a PCB with its own battery supply which is necessary to provide voltage for certain parts I need to debug.) I have tried replacing the probe with another to no success, too.

I’d appreciate if anyone has any advice on how to Picoprobe the slave Pico when it’s on a different voltage source (battery) to the probe. I have confirmed that the usual example code (blinky) will work if just dumped on as a UF2 to the slave pico- Picoprobe just can’t do anything with the slave.

tl;dr Current Issue Status: ongoing
Won’t probe with the slave pico having separate voltage source still
have rewired it to the picoprobe so that they have a common ground + source (vsys-ground on probe to match that of the slave pico)
This was to verify my PCB is fine and the slave is fine and the probe is fine: it is all fine. Probe works, code works, etc.
Why will it not work if the slave pico is on a separate voltage source?

Re: Picoprobing a Pico on a different voltage source: errors sending code over

Always connect the grounds to everything. SWD won’t work without it. Ground from SWD connector to Picoprobe ground as shown in the diagrams — three wires from probe to Pico being programmed.

Actually I just looked at the diagram and it shows two wires for SWD, two for UART, and two for power. All you really need for using Picoprobe with something like OpenOCD and a Pico that is externally powered is the three wires from the SWD connector to the Probe.

Re: Picoprobing a Pico on a different voltage source: errors sending code over

Always connect the grounds to everything. SWD won’t work without it. Ground from SWD connector to Picoprobe ground as shown in the diagrams — three wires from probe to Pico being programmed.

Actually I just looked at the diagram and it shows two wires for SWD, two for UART, and two for power. All you really need for using Picoprobe with something like OpenOCD and a Pico that is externally powered is the three wires from the SWD connector to the Probe.

Aye. I’ve tried to get it working but for some reason, the probe just can’t transfer over to the slave pico. I’m getting a lot of different errors, all do to with FLASH ROM. The main one thus far is.

«Failed to launch GDB: error erasing flash with vFlasherase packet (from target-download)»

If it gets past this, I get the pastebin I included in the original post. Thus far I’ve tried to.

— Replace the Pico (timely effort since it’s a castellated one and I have to desolder it all- I doubt two picos are bad, so I’m hesistant to try a third time.)
— Resolder the UART/DEBUG lines (they were fine according to the multimeter but yeah.)

Just to confirm whether I can get any code on the slave, I’ve just transferred it over mirco USB + bootsel’d it in, and it works fine, so clearly that’s not an issue.

Источник

Источник

I’m using a Nucleo STM32L031 with AC6 STM32 workbench (eclipse).

I write my application and go to debug mode, everthing was working well until I add another function in my application. I notice that when I remove/comment the «new_function«, the software can go to debug mode again. However when I add the «new_function» to the code and go to debug, an error occurs and it cannot go to debug mode.

Error: Error in final launch sequence
Failed to execute MI command:
load C:Project_STM32L031K6-Nucleo\Debug\Project.elf 

Error message from debugger back end:
Error erasing flash with vFlashErase packet
Error erasing flash with vFlashErase packet

This error does not occur only for this specific «new_function», but also for other functions e.g TIM21_Init() generated by STM32Cube.

I tried to search for the solution, but couldn’t find it.

Thanks
Bien

asked Aug 12, 2016 at 9:49

BL_'s user avatar

1

In my case (stm32f429) changing this option helped:
option to change

answered Jan 3, 2020 at 1:09

user1923363's user avatar

This is an OpenOCD issue, not a problem with your code. I got this issue when the debugger command file was referring to a «stlink-v2-1» but what I actually have is an «stlink-v2». I’m using the STM32F0 Discovery board.

I believe the Nucleo board has the «stlink-v2-1» so you might have the opposite problem as me. Check to make sure that the setting under «Run menu > Debug Configurations > Debugger > OpenOCD setup» is set to the correct debugger.

enter image description here

If a debug configuration file is being used (the «use default script» or «use local script» option is selected) open that file and look for a line like: 

source [find interface/stlink-v2.cfg]

In my case the project wizard had created a template that was referencing stlink-v2-1. Changing it to the above fixed the problem.

UPDATE:

I also got this problem when Eclipse crashed and left OpenOCD running in the background. Run

$ ps aux | grep openocd

And if you see an instance of OpenOCD running when the debugger is not, kill it.

answered Oct 12, 2016 at 2:33

bcattle's user avatar

bcattlebcattle

11.7k6 gold badges61 silver badges80 bronze badges

Источник

The Debugging host is a RPi 4, the target is a RP2040. I followed all of the Debug Setup guidance documented in «https://datasheets.raspberrypi.org/pico … h-pico.pdf». The command line debug test using two terminals, one running openocd and the other gdb_multiarch works.

It does not work from VS Code. Code executes CMake and Make properly then when it launches the openOCD logic it always fails.
The error displayed is «Failed to launch GDB: Error erasing flash with vFlashErase packet (from target-download)»

I can’t be the only to have encountered this issue.

I have included CS Code Adapter Output:
— openocd log —

Code: Select all

Open On-Chip Debugger 0.10.0+dev-gf8e14ec-dirty (2021-02-14-16:23)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : RP2040 Flash Bank Command
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : clock speed 1001 kHz
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x10000001
Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints
Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 50000
Info : Listening on port 50000 for gdb connections
Info : accepting 'gdb' connection on tcp/50000
Info : RP2040 B0 Flash Probe: 2097152 bytes @10000000, in 512 sectors

Info : New GDB Connection: 1, Target rp2040.core0, state: halted
undefined debug reason 8 - target needs reset
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
Error: JTAG failure 3
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x10000001
Error: JTAG failure 7
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x10000001
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x000000ee msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
Warn : target was in unknown state when halt was requested
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x00000001
Error: Failed to invoke ROM function RE (@000025e1)
Error: RP2040 erase: flash_range_erase failed
Error: failed erasing sectors 0 to 6
Error: flash_erase returned 7
Info : SWD DPIDR 0x0bc12477
Open On-Chip Debugger 0.10.0+dev-gf8e14ec-dirty (2021-02-14-16:23)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz

Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : RP2040 Flash Bank Command
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : clock speed 1001 kHz
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x10000001
Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints
Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 50000
Info : Listening on port 50000 for gdb connections
Info : accepting 'gdb' connection on tcp/50000
Info : RP2040 B0 Flash Probe: 2097152 bytes @10000000, in 512 sectors

Info : New GDB Connection: 1, Target rp2040.core0, state: halted
undefined debug reason 8 - target needs reset
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
Warn : target was in unknown state when halt was requested
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x00000001
Error: Failed to invoke ROM function RE (@000025e1)
Error: RP2040 erase: flash_range_erase failed
Error: failed erasing sectors 0 to 6
Error: flash_erase returned -302
Источник

STM32F76x Error erasing flash with vFlashErase packet #365

Comments

andrewleech commented Jul 3, 2018

Hi, I’m trying to debug a STM32F765 but it fails to load with Error erasing flash with vFlashErase packet
I’m using an stlink clone with firmware updated just now from: http://builds.blacksphere.co.nz/blackmagic
If it helps, current head is at d4d24c2

I previously had issues flashing with this part with a segger, the dual bank flash seemed to trip it up. Is it likely something similar here?

The text was updated successfully, but these errors were encountered:

UweBonnes commented Jul 3, 2018

Check the device option bits. Erase option bits and check again. If there is a differences,perhaps you accidental write protected the flash. Mass erase the device. Does that work? Can you flash after option and flash mass erase? If second flash does not work, check your programm that is does not do anything strange.

andrewleech commented Jul 3, 2018

As a test I switched to a different stlink converted to segger jlink and that works fine, no mass erase needed.

UweBonnes commented Jul 3, 2018

Please post the output of arm-none-eabi-size -x -A *elf

andrewleech commented Jul 3, 2018

UweBonnes commented Jul 3, 2018

I could try to flash your elf file to a nucleo-f767 if you make it available.

andrewleech commented Jul 3, 2018

I can share it tomorrow when I’m back in the office however it’s based on this so should be completely compatible with the elf here:

I haven’t tried flashing the elf directly from these guys though.

Источник

SparkFun Forums

Where electronics enthusiasts find answers.

STLink2 problems reseting

STLink2 problems reseting #192924

Im trying to get STM32F103, STLink 2.0, OpenOCD, Windows 10, and eclipse to work togeter.

I have several sets of the STMF103 2$ target, and STlink boards from AliExpress.

Some moths ago, i had everything running from Eclipse, build, upload, single step etc.
Then I had to enable some new peripheral on the STMF1x, and regenerated the project via. STMCube. (And I also updated the OpenOCD, the GNU toolchain, and the STM CMSIS, argh..)
Since I have not been able to get the darn thing to reset..

I have tried with both versions of the scrips, and can’t see any difference..

I have connected the NRST from the ST-Link to the target HW reset pin. (Classic RC pullup reset circuit on target)

Error message from Eclipse, debug, launch dialog:

I have tried at lot of different things on my Windows 10:
— Testing with STM-32 ST Link utility (Works, can drive HW reset, checked on scope)
— Trying different reset_config settings (More on this later)
— Different target, and STLink boards. (No difference)
— Perform reeinstalation of complete toolchain in another folder, inc. OpenOCD (No difference)
— Starting openocd.exe from command line, and connect with putty. (Does not work, More on this later)

In have also tested on a Ubuntu 16.04 LTS
— Starting openocd from shell, and connect with telnet. (Works, can drive HW reset, More on this later)

The command “ocd_reset init” behaves different:
— On windows it fails, and it does not drive reset pin.
— On Linux it succeeds, and drives the HW reset.

Источник

OpenSTM32 Community

The STM32 Systems Resource

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

With System Workbench for Linux , Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

  • Video: Simultaneous debug of Linux and bare-metal applications.
  • Video: Motor control by gestures (image processing on Cortex-A7/Linux, real-time on bare metal Cortex-M4).
  • White paper: Asymmetric Multi-Programming with System Workbench for Linux .
  • White paper: Creating an STM32MP1 Linux platform with System Workbench for Linux .

System Workbench for STM32

Launching SW4STM32 debug fails

Hello hopefully my last topic before starting learning from code for good,

I have my Eclipse-SW4STM32 project built, I can use the binary to fly the drone : the software looks working without major issue.
I have managed to launch a Texane/STLink GDB server by command line, with a STLink probe to connect to my custom F4 board : I can reach main breakpoint without issue.
Although, when I launch a debug session via Eclipse, it crashes during loading :

— here is the console output : https://pastebin.com/Y2wNER8b.

— here is the warning message “Error in final launch sequence
Failed to execute MI command:
load /home/maxzor/eclipse/workspace-pixracer/pixracer/obj/main/inav_PIXRACER.elf

Error message from debugger back end:
Error erasing flash with vFlashErase packet
Error erasing flash with vFlashErase packet”

-here is the content of .cfg script

  1. This is an Pixracer board with a single STM32F427VITx chip
  2. Generated by System Workbench for STM32
  3. Take care that such file, as generated, may be overridden without any early notice. Please have a look to debug launch configuration setup(s)

set WORKAREASIZE 0x8000

transport select “hla_swd”

set CHIPNAME STM32F427VITx

  1. Enable debug when in low power modes

set ENABLE_LOW_POWER 1

  1. Stop Watchdog counters when halt

set STOP_WATCHDOG 1

  1. STlink Debug clock frequency

set CLOCK_FREQ 4000

  1. use hardware reset, connect under reset
  2. connect_assert_srst needed if low power mode application running (WFI. )

reset_config srst_only srst_nogate connect_assert_srst
set CONNECT_UNDER_RESET 1

Any ideas?
Best regards

Источник

OpenSTM32 Community

The STM32 Systems Resource

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

With System Workbench for Linux , Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

  • Video: Simultaneous debug of Linux and bare-metal applications.
  • Video: Motor control by gestures (image processing on Cortex-A7/Linux, real-time on bare metal Cortex-M4).
  • White paper: Asymmetric Multi-Programming with System Workbench for Linux .
  • White paper: Creating an STM32MP1 Linux platform with System Workbench for Linux .

System Workbench for STM32

Unable to debug/program NUCLEO-F303K8

I was planning on having some fun with my NUCLEO-F303K8 board today but before I got that far I stumbled upon some problems. I am using System Workbench 1.13.1 on Windows 10 (x64).

When I try to debug my application I get the following error message (at 93%):

Error in final launch sequence
Failed to execute MI command:
load D:DanielSystemWorkbenchworkspaceMLX90614DebugMLX90614.elf

Error message from debugger back end:
Error erasing flash with vFlashErase packet
Error erasing flash with vFlashErase packet

When I check the openocd console I see the following:

Error: timed out while waiting for target halted
TARGET: stm32f3x.cpu — Not halted
in procedure ‘reset’
in procedure ‘ocd_bouncer’

I get that error three times, then at the end:

Error: Target not halted
Error: failed erasing sectors 0 to 1
Error: flash_erase returned -304

There seems to be a similar problem in this thread but I did not get it to work with the proposed solutions. Anyone have any other suggestions?

Another strange problem I have is that I tried to program my board using ST-LINK utility but it doesn’t detect it, so I cannot connect to it. All it says is “cannot connect to target” and suggests I go to settings and choose “connect under reset”, but I see no such option.

I know I must have managed to program the board a couple of month ago when I bought it because the demo application that was on it is no longer running when I connect the usb cord. I have updated the firmware a couple of times but it has always succeeded.

So I can connect in order to upgrade the ST-LINK firmware but not to do anything else it seems.

Источник

Necromancer’s notes

Lulz Driven Development

Заметка для себя: Как шить .bin файл при помощи “сырого” gdb

На первый взгляд очень простая задача, но когда работаешь с микроконтроллером через какой-нибудь gdb стаб/openocd, а память в которую подгружаем файл на самом деле флеш память микроконтроллера, (например, stm32) возникают нюансы. Решил собрать все шаманства в одном посте.

Типичный стартовый набор: китайский stlink перешитый в black magic probe и stm32f4 discovery

Итак, загрузку файла в память штатно gdb может делать двумя командами: load и restore. Если gdb подцепляется к openocd серверу, то у нас также есть пара команд монитора для программирования флеша.

  • load – понимает только elf файлы, подгружает все секции по адресам, в т.ч. во флеш.
  • restore – может загружать bin файлы по произвольному адресу. Но в случае попытки прогрузить во флеш-память кидает ошибку.
  • monitor flash write_bank – поддерживается только если мы подключаемся через OpenOCD. Но может грузить бинарные файлы.

Неприятность заключается в том, что команда monitor flash write_bank доступна только если мы работаем через OpenOCD, а restore на опробованных мною комбинациях отладчик/таргет всегда кидал ошибку. В итоге оставалась только команда load.

Проблем никаких, если мы собираем прошивку сами, и у нас есть исходники. Проблемы начинаются, если нам нужно прописать во флешку данные (например, конфиг), или готовую, скачанную из интернета прошивку, которая доступна только в виде bin файла.

В этом случае потребуются шаманства, а именно сделать из .bin elf, при этом меняя адрес единственной в этом файле секции .data на адрес флеша, куда мы будем загружать файл. На примере stm32, это можно сделать вот таким вот заклинанием. Оно скушает app.bin и выплюнет нам app.elf

arm-none-eabi-objcopy -I binary -O elf32-littlearm –change-section-address=.data=0x8000000 -B arm -S app.bin app.elf

Для других архитектур/микроконтроллеров придется поменять адрес секции .data (выделено курсивом), выходную архитектуру и вариант (выделены жирным). objcopy тоже лучше использовать из состава тулчейна для этого микроконтроллера.

Прогрузка файла через gdb (На примере black magic probe) будет выглядеть так:

Если эта команда ругается на Error erasing flash with vFlashErase packet, (например, если перед этим мы стирали option bytes’ы), то надо передернуть питание целевого мк и сделать mon_swdpscan заново.

Источник

Источник

I just installed r1454 after using r717 for a long time.

I had it working on my target, but after an afternoon of work I started to get «Error erasing flash with vFlashErase packet» when trying to run the load comand. When I revert to r717 it works OK.

I have no problem erasing the flash via telnet with the flash erase_sectorflash erase_sector 0 0 26 command. And when I do, the the load command works again for a while. But eventually it will break again and I have to manualy erase the flash. Any hints as to why this would happen? Following is the debug log.

[ My target is actually an LPC2368 w/ 12MHz xtal, but the 2148 configuration has always worked in the past.]

Code: Select all

User : 9 0 command.c:494 command_run_line(): 
Debug: 10 0 configuration.c:88 find_file(): found interfaceolimex-arm-usb-ocd.cfg
Debug: 12 0 command.c:91 script_command(): script_command - interface
Debug: 13 0 command.c:108 script_command(): script_command - interface, argv[0]=ocd_interface
Debug: 14 0 command.c:108 script_command(): script_command - interface, argv[1]=ft2232
Debug: 16 0 command.c:91 script_command(): script_command - ft2232_device_desc
Debug: 17 0 command.c:108 script_command(): script_command - ft2232_device_desc, argv[0]=ocd_ft2232_device_desc
Debug: 18 0 command.c:108 script_command(): script_command - ft2232_device_desc, argv[1]=Olimex OpenOCD JTAG A
Debug: 20 0 command.c:91 script_command(): script_command - ft2232_layout
Debug: 21 0 command.c:108 script_command(): script_command - ft2232_layout, argv[0]=ocd_ft2232_layout
Debug: 22 0 command.c:108 script_command(): script_command - ft2232_layout, argv[1]=olimex-jtag
Debug: 24 0 command.c:91 script_command(): script_command - ft2232_vid_pid
Debug: 25 16 command.c:108 script_command(): script_command - ft2232_vid_pid, argv[0]=ocd_ft2232_vid_pid
Debug: 26 16 command.c:108 script_command(): script_command - ft2232_vid_pid, argv[1]=0x15ba
Debug: 27 16 command.c:108 script_command(): script_command - ft2232_vid_pid, argv[2]=0x0003
User : 28 16 command.c:494 command_run_line(): 
Debug: 30 16 command.c:91 script_command(): script_command - jtag_khz
Debug: 31 16 command.c:108 script_command(): script_command - jtag_khz, argv[0]=ocd_jtag_khz
Debug: 32 16 command.c:108 script_command(): script_command - jtag_khz, argv[1]=1500
Debug: 33 16 jtag.c:2606 handle_jtag_khz_command(): handle jtag khz
User : 34 16 command.c:383 command_print(): 1500 kHz
User : 35 16 command.c:494 command_run_line(): 
Debug: 36 16 configuration.c:88 find_file(): found targetlpc2148.cfg
Debug: 38 16 command.c:91 script_command(): script_command - jtag_nsrst_delay
Debug: 39 16 command.c:108 script_command(): script_command - jtag_nsrst_delay, argv[0]=ocd_jtag_nsrst_delay
Debug: 40 16 command.c:108 script_command(): script_command - jtag_nsrst_delay, argv[1]=200
Debug: 42 16 command.c:91 script_command(): script_command - jtag_ntrst_delay
Debug: 43 16 command.c:108 script_command(): script_command - jtag_ntrst_delay, argv[0]=ocd_jtag_ntrst_delay
Debug: 44 16 command.c:108 script_command(): script_command - jtag_ntrst_delay, argv[1]=200
Debug: 46 16 command.c:91 script_command(): script_command - reset_config
Debug: 47 16 command.c:108 script_command(): script_command - reset_config, argv[0]=ocd_reset_config
Debug: 48 16 command.c:108 script_command(): script_command - reset_config, argv[1]=trst_and_srst
Debug: 49 16 command.c:108 script_command(): script_command - reset_config, argv[2]=srst_pulls_trst
Debug: 50 16 jtag.c:1853 jim_newtap_cmd(): Creating New Tap, Chip: lpc2148, Tap: cpu, Dotted: lpc2148.cpu, 8 params
Debug: 51 16 jtag.c:1872 jim_newtap_cmd(): Processing option: -irlen
Debug: 52 16 jtag.c:1872 jim_newtap_cmd(): Processing option: -ircapture
Debug: 53 16 jtag.c:1872 jim_newtap_cmd(): Processing option: -irmask
Debug: 54 16 jtag.c:1872 jim_newtap_cmd(): Processing option: -expected-id
Debug: 55 16 jtag.c:1985 jim_newtap_cmd(): Created Tap: lpc2148.cpu @ abs position 0, irlen 4, capture: 0x1 mask: 0xf
Debug: 56 16 target.c:3961 jim_target(): Target command params:
Debug: 57 16 target.c:3962 jim_target(): target create lpc2148.cpu arm7tdmi -endian little -chain-position lpc2148.cpu -variant arm7tdmi-s_r4 
Debug: 59 16 command.c:91 script_command(): script_command - bank
Debug: 60 16 command.c:108 script_command(): script_command - bank, argv[0]=ocd_flash_bank
Debug: 61 16 command.c:108 script_command(): script_command - bank, argv[1]=lpc2000
Debug: 62 16 command.c:108 script_command(): script_command - bank, argv[2]=0x0
Debug: 63 16 command.c:108 script_command(): script_command - bank, argv[3]=0x7d000
Debug: 64 16 command.c:108 script_command(): script_command - bank, argv[4]=0
Debug: 65 16 command.c:108 script_command(): script_command - bank, argv[5]=0
Debug: 66 16 command.c:108 script_command(): script_command - bank, argv[6]=0
Debug: 67 16 command.c:108 script_command(): script_command - bank, argv[7]=lpc2000_v2
Debug: 68 16 command.c:108 script_command(): script_command - bank, argv[8]=12000
User : 69 16 command.c:494 command_run_line(): 
Debug: 71 16 command.c:91 script_command(): script_command - init
Debug: 72 16 command.c:108 script_command(): script_command - init, argv[0]=ocd_init
Debug: 73 16 openocd.c:126 handle_init_command(): target init complete
Debug: 74 16 ft2232.c:1540 ft2232_init_ftd2xx(): 'ft2232' interface using FTD2XX with 'olimex-jtag' layout (15ba:0003)
Debug: 75 47 ft2232.c:1651 ft2232_init_ftd2xx(): current latency timer: 2
Debug: 76 47 ft2232.c:2079 olimex_jtag_init(): 80 08 1b
Debug: 77 47 ft2232.c:2122 olimex_jtag_init(): 82 09 0f
Debug: 78 47 ft2232.c:294 ft2232_speed(): 86 03 00
Debug: 79 63 openocd.c:133 handle_init_command(): jtag interface init complete
Debug: 80 63 jtag.c:2201 jtag_init_inner(): Init JTAG chain
Debug: 81 63 jtag.c:390 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST)
Debug: 82 63 jtag.c:1450 jtag_reset_callback(): -
Debug: 83 63 jtag.c:390 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST)
Debug: 84 63 jtag.c:1450 jtag_reset_callback(): -
Info : 85 78 jtag.c:1570 jtag_examine_chain(): JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
Info : 86 78 jtag.c:1608 jtag_examine_chain(): JTAG Tap/device matched
Debug: 87 78 jtag.c:390 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST)
Debug: 88 78 jtag.c:1450 jtag_reset_callback(): -
Debug: 89 78 openocd.c:139 handle_init_command(): jtag init complete
Warn : 90 78 embeddedice.c:191 embeddedice_build_reg_cache(): EmbeddedICE version 7 detected, EmbeddedICE handling might be broken
Debug: 91 78 embeddedice.c:401 embeddedice_write_reg(): 0: 0x00000004
Debug: 92 78 embeddedice.c:401 embeddedice_write_reg(): 12: 0x00000000
Debug: 93 78 embeddedice.c:401 embeddedice_write_reg(): 20: 0x00000000
Debug: 94 78 openocd.c:142 handle_init_command(): jtag examine complete
Debug: 95 78 openocd.c:148 handle_init_command(): flash init complete
Debug: 96 78 openocd.c:152 handle_init_command(): mflash init complete
Debug: 97 78 openocd.c:156 handle_init_command(): NAND init complete
Debug: 98 78 openocd.c:160 handle_init_command(): pld init complete
Warn : 99 78 telnet_server.c:612 telnet_init(): no telnet port specified, using default port 4444
Warn : 100 78 gdb_server.c:2201 gdb_init(): no gdb port specified, using default port 3333
Debug: 101 78 gdb_server.c:2225 gdb_init(): gdb service for target arm7tdmi at port 3333
Warn : 102 78 tcl_server.c:178 tcl_init(): no tcl port specified, using default port 6666
User : 103 78 command.c:494 command_run_line(): 
Info : 104 7813 server.c:89 add_connection(): accepting 'gdb' connection from 0
Debug: 105 7813 arm7_9_common.c:1054 arm7_9_halt(): target->state: running
Debug: 106 7813 embeddedice.c:401 embeddedice_write_reg(): 9: 0xffffffff
Debug: 107 7813 embeddedice.c:401 embeddedice_write_reg(): 11: 0xffffffff
Debug: 108 7813 embeddedice.c:401 embeddedice_write_reg(): 12: 0x00000100
Debug: 109 7813 embeddedice.c:401 embeddedice_write_reg(): 13: 0x000000f7
Debug: 110 7813 embeddedice.c:401 embeddedice_write_reg(): 0: 0x00000005
Debug: 111 7813 embeddedice.c:401 embeddedice_write_reg(): 12: 0x00000000
Debug: 112 7813 arm7_9_common.c:1153 arm7_9_debug_entry(): target entered debug from ARM state
Debug: 113 7813 arm7_9_common.c:1185 arm7_9_debug_entry(): target entered debug state in Abort mode
Debug: 114 7813 arm7_9_common.c:1216 arm7_9_debug_entry(): r0: 0x00000000
Debug: 115 7813 arm7_9_common.c:1216 arm7_9_debug_entry(): r1: 0xe0064c00
Debug: 116 7813 arm7_9_common.c:1216 arm7_9_debug_entry(): r2: 0xe0064c08
Debug: 117 7813 arm7_9_common.c:1216 arm7_9_debug_entry(): r3: 0x00e05b64
Debug: 118 7813 arm7_9_common.c:1216 arm7_9_debug_entry(): r4: 0xffffffff
Debug: 119 7813 arm7_9_common.c:1216 arm7_9_debug_entry(): r5: 0xffffffff
Debug: 120 7813 arm7_9_common.c:1216 arm7_9_debug_entry(): r6: 0xffffffff
Debug: 121 7813 arm7_9_common.c:1216 arm7_9_debug_entry(): r7: 0xffffffff
Debug: 122 7813 arm7_9_common.c:1216 arm7_9_debug_entry(): r8: 0xffffffff
Debug: 123 7813 arm7_9_common.c:1216 arm7_9_debug_entry(): r9: 0xffffffff
Debug: 124 7813 arm7_9_common.c:1216 arm7_9_debug_entry(): r10: 0xffffffff
Debug: 125 7813 arm7_9_common.c:1216 arm7_9_debug_entry(): r11: 0x40007ef8
Debug: 126 7813 arm7_9_common.c:1216 arm7_9_debug_entry(): r12: 0x40007efc
Debug: 127 7813 arm7_9_common.c:1216 arm7_9_debug_entry(): r13: 0x40007eec
Debug: 128 7813 arm7_9_common.c:1216 arm7_9_debug_entry(): r14: 0x00005b44
Debug: 129 7813 arm7_9_common.c:1216 arm7_9_debug_entry(): r15: 0x00002500
Debug: 130 7813 arm7_9_common.c:1222 arm7_9_debug_entry(): entered debug state at PC 0x2500
Debug: 131 7813 target.c:697 target_call_event_callbacks(): target event 4 (early-halted)
Debug: 132 7813 target.c:3095 target_handle_event(): event: 4 early-halted - no action
Debug: 133 7813 target.c:3095 target_handle_event(): event: 4 early-halted - no action
Debug: 134 7813 target.c:697 target_call_event_callbacks(): target event 5 (halted)
Debug: 135 7813 target.c:3095 target_handle_event(): event: 5 halted - no action
User : 136 7813 target.c:949 target_arch_state(): target state: halted
User : 137 7813 armv4_5.c:316 armv4_5_arch_state(): target halted in ARM state due to debug-request, current mode: Abort
cpsr: 0x600000d7 pc: 0x00002500
Debug: 138 7813 target.c:3095 target_handle_event(): event: 5 halted - no action
Debug: 139 7813 target.c:697 target_call_event_callbacks(): target event 10 (gdb-end)
Debug: 140 7813 target.c:3095 target_handle_event(): event: 10 gdb-end - no action
Debug: 141 7813 target.c:3095 target_handle_event(): event: 10 gdb-end - no action
Debug: 142 7829 target.c:697 target_call_event_callbacks(): target event 26 (gdb-attach)
Debug: 143 7829 target.c:3095 target_handle_event(): event: 26 gdb-attach - no action
Debug: 144 7829 target.c:3095 target_handle_event(): event: 26 gdb-attach - no action
Debug: 145 7829 gdb_server.c:2050 gdb_input_inner(): received packet: 'qSupported'
Warn : 146 7829 gdb_server.c:586 gdb_get_packet_inner(): acknowledgment received, but no packet pending
Debug: 147 7829 gdb_server.c:2050 gdb_input_inner(): received packet: '?'
Debug: 148 7829 gdb_server.c:2050 gdb_input_inner(): received packet: 'Hc-1'
Debug: 149 7829 gdb_server.c:2050 gdb_input_inner(): received packet: 'qC'
Debug: 150 7829 gdb_server.c:2050 gdb_input_inner(): received packet: 'qOffsets'
Debug: 151 7829 gdb_server.c:2050 gdb_input_inner(): received packet: 'Hg0'
Debug: 152 7829 gdb_server.c:2050 gdb_input_inner(): received packet: 'g'
Debug: 153 7860 gdb_server.c:2050 gdb_input_inner(): received packet: 'qXfer:memory-map:read::0,fff'
Debug: 154 7860 gdb_server.c:2050 gdb_input_inner(): received packet: 'm2500,4'
Debug: 155 7860 gdb_server.c:1190 gdb_read_memory_packet(): addr: 0x00002500, len: 0x00000004
Debug: 156 7860 target.c:1040 target_read_buffer(): reading buffer of 4 byte at 0x00002500
Debug: 157 7860 arm7_9_common.c:1966 arm7_9_read_memory(): address: 0x00002500, size: 0x00000004, count: 0x00000001
Debug: 158 7860 gdb_server.c:2050 gdb_input_inner(): received packet: 'qSymbol::'
Debug: 159 7907 gdb_server.c:2050 gdb_input_inner(): received packet: 'qRcmd,726573657420696e6974'
Debug: 161 7907 command.c:91 script_command(): script_command - reset
Debug: 162 7907 command.c:108 script_command(): script_command - reset, argv[0]=ocd_reset
Debug: 163 7907 command.c:108 script_command(): script_command - reset, argv[1]=init
Debug: 164 7907 target.c:3961 jim_target(): Target command params:
Debug: 165 7907 target.c:3962 jim_target(): target names 
Debug: 166 7907 target.c:3095 target_handle_event(): event: 11 reset-start - no action
Debug: 167 7907 jtag.c:2234 jtag_init_reset(): Trying to bring the JTAG controller to life by asserting TRST / RESET
Debug: 168 7907 jtag.c:1142 jtag_add_reset(): SRST line released
Debug: 169 7907 jtag.c:1161 jtag_add_reset(): TRST line asserted
Debug: 170 7907 jtag.c:390 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST)
Debug: 171 7907 jtag.c:1450 jtag_reset_callback(): -
Debug: 172 7907 jtag.c:1138 jtag_add_reset(): SRST line asserted
Debug: 173 7907 jtag.c:1161 jtag_add_reset(): TRST line asserted
Debug: 174 7907 jtag.c:390 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST)
Debug: 175 7907 jtag.c:1450 jtag_reset_callback(): -
Debug: 176 7907 jtag.c:1142 jtag_add_reset(): SRST line released
Debug: 177 7907 ft2232.c:1115 olimex_jtag_reset(): trst: 1, srst: 0, high_output: 0x08, high_direction: 0x0f
Debug: 178 8220 ft2232.c:1115 olimex_jtag_reset(): trst: 1, srst: 1, high_output: 0x0a, high_direction: 0x0f
Debug: 179 8220 ft2232.c:1115 olimex_jtag_reset(): trst: 0, srst: 0, high_output: 0x09, high_direction: 0x0f
Debug: 181 8845 jtag.c:2201 jtag_init_inner(): Init JTAG chain
Debug: 182 8845 jtag.c:390 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST)
Debug: 183 8845 jtag.c:1450 jtag_reset_callback(): -
Info : 184 8845 jtag.c:1570 jtag_examine_chain(): JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
Info : 185 8845 jtag.c:1608 jtag_examine_chain(): JTAG Tap/device matched
Debug: 186 8845 jtag.c:390 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST)
Debug: 187 8845 jtag.c:1450 jtag_reset_callback(): -
Debug: 188 8845 target.c:3961 jim_target(): Target command params:
Debug: 189 8845 target.c:3962 jim_target(): target names 
Debug: 190 8845 embeddedice.c:401 embeddedice_write_reg(): 0: 0x00000000
Debug: 191 8845 embeddedice.c:401 embeddedice_write_reg(): 12: 0x00000000
Debug: 192 8845 embeddedice.c:401 embeddedice_write_reg(): 20: 0x00000000
Debug: 193 8845 target.c:3961 jim_target(): Target command params:
Debug: 194 8845 target.c:3962 jim_target(): target names 
Debug: 195 8845 target.c:3095 target_handle_event(): event: 12 reset-assert-pre - no action
Debug: 196 8845 arm7_9_common.c:810 arm7_9_assert_reset(): target->state: halted
Debug: 197 8845 embeddedice.c:401 embeddedice_write_reg(): 8: 0x00000000
Debug: 198 8845 embeddedice.c:401 embeddedice_write_reg(): 9: 0x00000003
Debug: 199 8845 embeddedice.c:401 embeddedice_write_reg(): 11: 0xffffffff
Debug: 200 8845 embeddedice.c:401 embeddedice_write_reg(): 12: 0x00000100
Debug: 201 8845 embeddedice.c:401 embeddedice_write_reg(): 13: 0x000000f7
Debug: 202 8845 jtag.c:1138 jtag_add_reset(): SRST line asserted
Debug: 203 8845 jtag.c:1161 jtag_add_reset(): TRST line asserted
Debug: 204 8845 jtag.c:390 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST)
Debug: 205 8845 jtag.c:1450 jtag_reset_callback(): -
Debug: 206 8845 target.c:3095 target_handle_event(): event: 13 reset-assert-post - no action
Debug: 207 8845 target.c:3961 jim_target(): Target command params:
Debug: 208 8845 target.c:3962 jim_target(): target names 
Debug: 209 8845 target.c:3095 target_handle_event(): event: 14 reset-deassert-pre - no action
Debug: 210 8845 arm7_9_common.c:870 arm7_9_deassert_reset(): target->state: reset
Debug: 211 8845 jtag.c:1142 jtag_add_reset(): SRST line released
Warn : 212 8845 arm7_9_common.c:877 arm7_9_deassert_reset(): srst pulls trst - can not reset into halted mode. Issuing halt after reset.
Debug: 213 8845 ft2232.c:1115 olimex_jtag_reset(): trst: 1, srst: 1, high_output: 0x0a, high_direction: 0x0f
Debug: 214 8923 ft2232.c:1115 olimex_jtag_reset(): trst: 0, srst: 0, high_output: 0x09, high_direction: 0x0f
Debug: 216 9548 embeddedice.c:401 embeddedice_write_reg(): 0: 0x00000000
Debug: 217 9548 embeddedice.c:401 embeddedice_write_reg(): 12: 0x00000000
Debug: 218 9548 embeddedice.c:401 embeddedice_write_reg(): 20: 0x00000000
Debug: 219 9548 arm7_9_common.c:1054 arm7_9_halt(): target->state: running
Debug: 220 9548 embeddedice.c:401 embeddedice_write_reg(): 9: 0xffffffff
Debug: 221 9548 embeddedice.c:401 embeddedice_write_reg(): 11: 0xffffffff
Debug: 222 9548 embeddedice.c:401 embeddedice_write_reg(): 12: 0x00000100
Debug: 223 9548 embeddedice.c:401 embeddedice_write_reg(): 13: 0x000000f7
Debug: 224 9548 target.c:3095 target_handle_event(): event: 15 reset-deassert-post - no action
Debug: 225 9548 target.c:3961 jim_target(): Target command params:
Debug: 226 9548 target.c:3962 jim_target(): target names 
Debug: 227 9548 embeddedice.c:401 embeddedice_write_reg(): 0: 0x00000005
Debug: 228 9548 embeddedice.c:401 embeddedice_write_reg(): 12: 0x00000000
Debug: 229 9548 arm7_9_common.c:1153 arm7_9_debug_entry(): target entered debug from ARM state
Debug: 230 9548 arm7_9_common.c:1185 arm7_9_debug_entry(): target entered debug state in System mode
Debug: 231 9548 arm7_9_common.c:1216 arm7_9_debug_entry(): r0: 0x00000001
Debug: 232 9548 arm7_9_common.c:1216 arm7_9_debug_entry(): r1: 0x00003000
Debug: 233 9548 arm7_9_common.c:1216 arm7_9_debug_entry(): r2: 0x000114e7
Debug: 234 9548 arm7_9_common.c:1216 arm7_9_debug_entry(): r3: 0x000fffff
Debug: 235 9548 arm7_9_common.c:1216 arm7_9_debug_entry(): r4: 0x4000588c
Debug: 236 9548 arm7_9_common.c:1216 arm7_9_debug_entry(): r5: 0x05050505
Debug: 237 9548 arm7_9_common.c:1216 arm7_9_debug_entry(): r6: 0x06060606
Debug: 238 9548 arm7_9_common.c:1216 arm7_9_debug_entry(): r7: 0x07070707
Debug: 239 9548 arm7_9_common.c:1216 arm7_9_debug_entry(): r8: 0x08080808
Debug: 240 9548 arm7_9_common.c:1216 arm7_9_debug_entry(): r9: 0x09090909
Debug: 241 9548 arm7_9_common.c:1216 arm7_9_debug_entry(): r10: 0x10101010
Debug: 242 9548 arm7_9_common.c:1216 arm7_9_debug_entry(): r11: 0x40005830
Debug: 243 9548 arm7_9_common.c:1216 arm7_9_debug_entry(): r12: 0x40005810
Debug: 244 9548 arm7_9_common.c:1216 arm7_9_debug_entry(): r13: 0x40005810
Debug: 245 9548 arm7_9_common.c:1216 arm7_9_debug_entry(): r14: 0x00006038
Debug: 246 9548 arm7_9_common.c:1216 arm7_9_debug_entry(): r15: 0x00006034
Debug: 247 9548 arm7_9_common.c:1222 arm7_9_debug_entry(): entered debug state at PC 0x6034
Debug: 248 9548 target.c:697 target_call_event_callbacks(): target event 4 (early-halted)
Debug: 249 9548 target.c:3095 target_handle_event(): event: 4 early-halted - no action
Debug: 250 9548 target.c:3095 target_handle_event(): event: 4 early-halted - no action
Debug: 251 9548 target.c:697 target_call_event_callbacks(): target event 5 (halted)
Debug: 252 9548 target.c:3095 target_handle_event(): event: 5 halted - no action
User : 253 9548 target.c:949 target_arch_state(): target state: halted
User : 254 9548 armv4_5.c:316 armv4_5_arch_state(): target halted in ARM state due to debug-request, current mode: System
cpsr: 0x8000001f pc: 0x00006034
Debug: 255 9548 target.c:3095 target_handle_event(): event: 5 halted - no action
Debug: 256 9548 target.c:697 target_call_event_callbacks(): target event 10 (gdb-end)
Debug: 257 9548 target.c:3095 target_handle_event(): event: 10 gdb-end - no action
Debug: 258 9548 target.c:3095 target_handle_event(): event: 10 gdb-end - no action
Debug: 259 9548 target.c:3961 jim_target(): Target command params:
Debug: 260 9548 target.c:3962 jim_target(): target names 
Debug: 261 9548 target.c:3084 target_handle_event(): target: (0) lpc2148.cpu (arm7tdmi) event: 20 (reset-init) action: 
	# Force target into ARM state.
	soft_reset_halt

	# Do not remap 0x0000-0x0020 to anything but the flash (i.e. select
	# "User Flash Mode" where interrupt vectors are _not_ remapped,
	# and reside in flash instead).
	#
	# See section 7.1 on page 32 ("Memory Mapping control register") in
	# "UM10139: Volume 1: LPC214x User Manual", Rev. 02 -- 25 July 2006.
	# http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/user.manual.lpc2141.lpc2142.lpc2144.lpc2146.lpc2148.pdf
	mwb 0xE01FC040 0x01


Debug: 263 9548 command.c:91 script_command(): script_command - soft_reset_halt
Debug: 264 9548 command.c:108 script_command(): script_command - soft_reset_halt, argv[0]=ocd_soft_reset_halt
User : 265 9548 target.c:1783 handle_soft_reset_halt_command(): requesting target halt and executing a soft reset
Debug: 266 9548 arm7_9_common.c:1054 arm7_9_halt(): target->state: halted
Debug: 267 9548 arm7_9_common.c:1058 arm7_9_halt(): target was already halted
Debug: 268 9548 embeddedice.c:401 embeddedice_write_reg(): 0: 0x00000005
Debug: 269 9548 embeddedice.c:401 embeddedice_write_reg(): 12: 0x00000000
Debug: 270 9548 target.c:697 target_call_event_callbacks(): target event 4 (early-halted)
Debug: 271 9548 target.c:3095 target_handle_event(): event: 4 early-halted - no action
Debug: 272 9548 target.c:3095 target_handle_event(): event: 4 early-halted - no action
Debug: 273 9548 target.c:697 target_call_event_callbacks(): target event 5 (halted)
Debug: 274 9548 target.c:3095 target_handle_event(): event: 5 halted - no action
User : 275 9548 target.c:949 target_arch_state(): target state: halted
User : 276 9548 armv4_5.c:316 armv4_5_arch_state(): target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x800000d3 pc: 0x00000000
Debug: 277 9548 target.c:3095 target_handle_event(): event: 5 halted - no action
Debug: 278 9548 target.c:697 target_call_event_callbacks(): target event 10 (gdb-end)
Debug: 279 9548 target.c:3095 target_handle_event(): event: 10 gdb-end - no action
Debug: 280 9548 target.c:3095 target_handle_event(): event: 10 gdb-end - no action
Debug: 282 9563 command.c:91 script_command(): script_command - mwb
Debug: 283 9563 command.c:108 script_command(): script_command - mwb, argv[0]=ocd_mwb
Debug: 284 9563 command.c:108 script_command(): script_command - mwb, argv[1]=0xE01FC040
Debug: 285 9563 command.c:108 script_command(): script_command - mwb, argv[2]=0x01
Debug: 286 9563 embeddedice.c:401 embeddedice_write_reg(): 0: 0x00000004
Debug: 287 9563 embeddedice.c:401 embeddedice_write_reg(): 0: 0x00000005
Debug: 288 9563 target.c:3961 jim_target(): Target command params:
Debug: 289 9563 target.c:3962 jim_target(): target names 
Debug: 290 9563 target.c:3095 target_handle_event(): event: 21 reset-end - no action
User : 291 9563 command.c:494 command_run_line(): 
Debug: 292 9657 gdb_server.c:2050 gdb_input_inner(): received packet: 'qRcmd,736c65657020353030'
Debug: 294 9657 command.c:91 script_command(): script_command - sleep
Debug: 295 9657 command.c:108 script_command(): script_command - sleep, argv[0]=ocd_sleep
Debug: 296 9657 command.c:108 script_command(): script_command - sleep, argv[1]=500
User : 297 10157 command.c:494 command_run_line(): 
Debug: 298 10204 gdb_server.c:2050 gdb_input_inner(): received packet: 'qRcmd,6d7777203078453031464330343020307830303031'
Debug: 300 10204 command.c:91 script_command(): script_command - mww
Debug: 301 10204 command.c:108 script_command(): script_command - mww, argv[0]=ocd_mww
Debug: 302 10204 command.c:108 script_command(): script_command - mww, argv[1]=0xE01FC040
Debug: 303 10204 command.c:108 script_command(): script_command - mww, argv[2]=0x0001
Debug: 304 10204 embeddedice.c:401 embeddedice_write_reg(): 0: 0x00000004
Debug: 305 10204 embeddedice.c:401 embeddedice_write_reg(): 0: 0x00000005
User : 306 10204 command.c:494 command_run_line(): 
Debug: 307 10313 gdb_server.c:2050 gdb_input_inner(): received packet: 'qRcmd,6d64772030784530314643303430'
Debug: 309 10313 command.c:91 script_command(): script_command - mdw
Debug: 310 10313 command.c:108 script_command(): script_command - mdw, argv[0]=ocd_mdw
Debug: 311 10313 command.c:108 script_command(): script_command - mdw, argv[1]=0xE01FC040
Debug: 312 10313 arm7_9_common.c:1966 arm7_9_read_memory(): address: 0xe01fc040, size: 0x00000004, count: 0x00000001
User : 313 10313 command.c:383 command_print(): 0xe01fc040: 00000001 
User : 314 10313 command.c:494 command_run_line(): 
Debug: 315 10423 gdb_server.c:2050 gdb_input_inner(): received packet: 'qRcmd,61726d375f39206463635f646f776e6c6f61647320656e61626c65'
Debug: 317 10423 command.c:91 script_command(): script_command - dcc_downloads
Debug: 318 10423 command.c:108 script_command(): script_command - dcc_downloads, argv[0]=ocd_arm7_9_dcc_downloads
Debug: 319 10423 command.c:108 script_command(): script_command - dcc_downloads, argv[1]=enable
User : 320 10423 command.c:383 command_print(): dcc downloads are enabled
User : 321 10423 command.c:494 command_run_line(): 
Debug: 322 10642 gdb_server.c:2050 gdb_input_inner(): received packet: 'vFlashErase:00000000,00051000'
Debug: 323 10642 target.c:697 target_call_event_callbacks(): target event 28 (gdb-flash-erase-start)
Debug: 324 10642 target.c:3095 target_handle_event(): event: 28 gdb-flash-erase-start - no action
Debug: 325 10642 target.c:3095 target_handle_event(): event: 28 gdb-flash-erase-start - no action
Debug: 326 10642 target.c:3095 target_handle_event(): event: 0 old-gdb_program_config - no action
Debug: 327 10642 target.c:820 target_alloc_working_area(): allocating new working area
Debug: 328 10642 embeddedice.c:401 embeddedice_write_reg(): 0: 0x00000004
Debug: 329 10642 embeddedice.c:401 embeddedice_write_reg(): 0: 0x00000005
Debug: 330 10642 armv4_5.c:540 armv4_5_run_algorithm_inner(): Running algorithm
Debug: 331 10642 target.c:965 target_write_buffer(): writing buffer of 24 byte at 0x40000008
Debug: 332 10642 embeddedice.c:401 embeddedice_write_reg(): 0: 0x00000004
Debug: 333 10642 embeddedice.c:401 embeddedice_write_reg(): 0: 0x00000005
Debug: 334 10642 target.c:965 target_write_buffer(): writing buffer of 12 byte at 0x40000020
Debug: 335 10642 embeddedice.c:401 embeddedice_write_reg(): 0: 0x00000004
Debug: 336 10642 embeddedice.c:401 embeddedice_write_reg(): 0: 0x00000005
Debug: 337 10642 armv4_5.c:607 armv4_5_run_algorithm_inner(): setting core_mode: 0x13
Debug: 338 10642 embeddedice.c:401 embeddedice_write_reg(): 12: 0x00000000
Debug: 339 10642 embeddedice.c:401 embeddedice_write_reg(): 20: 0x00000000
Debug: 340 10657 embeddedice.c:401 embeddedice_write_reg(): 8: 0x40000004
Debug: 341 10657 embeddedice.c:401 embeddedice_write_reg(): 9: 0x00000003
Debug: 342 10657 embeddedice.c:401 embeddedice_write_reg(): 11: 0xffffffff
Debug: 343 10657 embeddedice.c:401 embeddedice_write_reg(): 13: 0x000000f7
Debug: 344 10657 embeddedice.c:401 embeddedice_write_reg(): 12: 0x00000100
Debug: 345 10657 breakpoints.c:93 breakpoint_add(): added hardware breakpoint at 0x40000004 of length 0x00000004
Debug: 346 10657 arm7_9_common.c:1527 arm7_9_resume(): -
Debug: 347 10657 embeddedice.c:401 embeddedice_write_reg(): 8: 0x40000004
Debug: 348 10657 embeddedice.c:401 embeddedice_write_reg(): 9: 0x00000003
Debug: 349 10657 embeddedice.c:401 embeddedice_write_reg(): 11: 0xffffffff
Debug: 350 10657 embeddedice.c:401 embeddedice_write_reg(): 13: 0x000000f7
Debug: 351 10657 embeddedice.c:401 embeddedice_write_reg(): 12: 0x00000100
Debug: 352 10657 arm7_9_common.c:1346 arm7_9_restore_context(): -
Debug: 353 10657 arm7_9_common.c:1365 arm7_9_restore_context(): examining User mode
Debug: 354 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: r0
Debug: 355 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: r1
Debug: 356 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: r2
Debug: 357 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: r3
Debug: 358 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: r4
Debug: 359 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: r5
Debug: 360 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: r6
Debug: 361 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: r7
Debug: 362 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: r8
Debug: 363 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: r9
Debug: 364 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: r10
Debug: 365 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: r11
Debug: 366 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: r12
Debug: 367 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: pc
Debug: 368 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: cpsr
Debug: 369 10657 arm7_9_common.c:1427 arm7_9_restore_context(): writing register 0 of mode User with value 0x40000008
Debug: 370 10657 arm7_9_common.c:1427 arm7_9_restore_context(): writing register 1 of mode User with value 0x40000020
Debug: 371 10657 arm7_9_common.c:1427 arm7_9_restore_context(): writing register 2 of mode User with value 0xffffffff
Debug: 372 10657 arm7_9_common.c:1427 arm7_9_restore_context(): writing register 3 of mode User with value 0xffffffff
Debug: 373 10657 arm7_9_common.c:1427 arm7_9_restore_context(): writing register 4 of mode User with value 0xffffffff
Debug: 374 10657 arm7_9_common.c:1427 arm7_9_restore_context(): writing register 5 of mode User with value 0xffffffff
Debug: 375 10657 arm7_9_common.c:1427 arm7_9_restore_context(): writing register 6 of mode User with value 0xffffffff
Debug: 376 10657 arm7_9_common.c:1427 arm7_9_restore_context(): writing register 7 of mode User with value 0xffffffff
Debug: 377 10657 arm7_9_common.c:1427 arm7_9_restore_context(): writing register 8 of mode User with value 0xffffffff
Debug: 378 10657 arm7_9_common.c:1427 arm7_9_restore_context(): writing register 9 of mode User with value 0xffffffff
Debug: 379 10657 arm7_9_common.c:1427 arm7_9_restore_context(): writing register 10 of mode User with value 0xffffffff
Debug: 380 10657 arm7_9_common.c:1427 arm7_9_restore_context(): writing register 11 of mode User with value 0xffffffff
Debug: 381 10657 arm7_9_common.c:1427 arm7_9_restore_context(): writing register 12 of mode User with value 0x7ffffff1
Debug: 382 10657 arm7_9_common.c:1365 arm7_9_restore_context(): examining FIQ mode
Debug: 383 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: pc
Debug: 384 10657 arm7_9_common.c:1365 arm7_9_restore_context(): examining IRQ mode
Debug: 385 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: pc
Debug: 386 10657 arm7_9_common.c:1365 arm7_9_restore_context(): examining Supervisor mode
Debug: 387 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: r13_svc
Debug: 388 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: lr_svc
Debug: 389 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: pc
Debug: 390 10657 arm7_9_common.c:1427 arm7_9_restore_context(): writing register 13 of mode Supervisor with value 0x400000ac
Debug: 391 10657 arm7_9_common.c:1427 arm7_9_restore_context(): writing register 14 of mode Supervisor with value 0x40000004
Debug: 392 10657 arm7_9_common.c:1365 arm7_9_restore_context(): examining Abort mode
Debug: 393 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: pc
Debug: 394 10657 arm7_9_common.c:1365 arm7_9_restore_context(): examining Undefined mode
Debug: 395 10657 arm7_9_common.c:1379 arm7_9_restore_context(): examining dirty reg: pc
Debug: 396 10657 arm7_9_common.c:1460 arm7_9_restore_context(): writing cpsr with value 0x800000d3
Debug: 397 10657 arm7tdmi.c:465 arm7tdmi_write_xpsr(): xpsr: 800000d3, spsr: 0
Debug: 398 10657 arm7_9_common.c:1467 arm7_9_restore_context(): writing PC with value 0x40000000
Debug: 399 10657 embeddedice.c:401 embeddedice_write_reg(): 0: 0x00000004
Debug: 400 10657 target.c:697 target_call_event_callbacks(): target event 23 (debug-resumed)
Debug: 401 10657 target.c:3095 target_handle_event(): event: 23 debug-resumed - no action
Debug: 402 10657 target.c:3095 target_handle_event(): event: 23 debug-resumed - no action
Debug: 403 10657 arm7_9_common.c:1674 arm7_9_resume(): target resumed
Debug: 404 10657 target.c:1735 target_wait_state(): waiting for target halted...
Error: 424 20658 target.c:1746 target_wait_state(): timed out while waiting for target halted
Debug: 425 20658 embeddedice.c:401 embeddedice_write_reg(): 12: 0x00000000
Debug: 426 20658 embeddedice.c:401 embeddedice_write_reg(): 12: 0x00000000
Debug: 427 20658 embeddedice.c:401 embeddedice_write_reg(): 20: 0x00000000
Warn : 428 20658 lpc2000.c:445 lpc2000_erase(): lpc2000 prepare sectors returned 11136720
Error: 429 20658 flash.c:126 flash_driver_erase(): failed erasing sectors 0 to 17 (-902)
Debug: 430 20658 target.c:697 target_call_event_callbacks(): target event 29 (gdb-flash-erase-end)
Debug: 431 20658 target.c:3095 target_handle_event(): event: 29 gdb-flash-erase-end - no action
Debug: 432 20658 target.c:3095 target_handle_event(): event: 29 gdb-flash-erase-end - no action
Error: 433 20658 gdb_server.c:1885 gdb_v_packet(): flash_erase returned -902
Debug: 434 20736 gdb_server.c:2050 gdb_input_inner(): received packet: 'qfThreadInfo'
Debug: 435 20736 gdb_server.c:2050 gdb_input_inner(): received packet: 'qL1200000000000000000'
Debug: 436 20736 gdb_server.c:2050 gdb_input_inner(): received packet: 'qC'
Debug: 437 20861 gdb_server.c:2050 gdb_input_inner(): received packet: 'm40007ef4,4'
Debug: 438 20861 gdb_server.c:1190 gdb_read_memory_packet(): addr: 0x40007ef4, len: 0x00000004
Debug: 439 20861 target.c:1040 target_read_buffer(): reading buffer of 4 byte at 0x40007ef4
Debug: 440 20861 arm7_9_common.c:1966 arm7_9_read_memory(): address: 0x40007ef4, size: 0x00000004, count: 0x00000001
Warn : 441 20877 arm7_9_common.c:1970 arm7_9_read_memory(): target not halted
Debug: 442 20877 gdb_server.c:2050 gdb_input_inner(): received packet: 'm0,4'
Debug: 443 20877 gdb_server.c:1190 gdb_read_memory_packet(): addr: 0x00000000, len: 0x00000004
Debug: 444 20877 target.c:1040 target_read_buffer(): reading buffer of 4 byte at 0x00000000
Debug: 445 20877 arm7_9_common.c:1966 arm7_9_read_memory(): address: 0x00000000, size: 0x00000004, count: 0x00000001
Warn : 446 20877 arm7_9_common.c:1970 arm7_9_read_memory(): target not halted
Debug: 447 29346 gdb_server.c:2050 gdb_input_inner(): received packet: 'k'
Debug: 448 29346 target.c:697 target_call_event_callbacks(): target event 10 (gdb-end)
Debug: 449 29346 target.c:3095 target_handle_event(): event: 10 gdb-end - no action
Debug: 450 29346 target.c:697 target_call_event_callbacks(): target event 27 (gdb-detach)
Debug: 451 29346 target.c:3095 target_handle_event(): event: 27 gdb-detach - no action
Info : 452 29346 server.c:452 server_loop(): dropped 'gdb' connection - error -400
Источник

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • 1

    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?

    • 2

    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:

    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.

    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.

    • 3

    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

    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.

    • 4

    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

    • 5

    Hi Bernhard,

    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.

    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

    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.

    • 6

    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?

    • 7

    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

  • Share

Источник

Понравилась статья? Поделить с друзьями:
  • Failed to load dll from the list error code 988
  • Failed to launch denuvo license generator error code 2
  • Failed to load dll from the list error code 225 как исправить
  • Failed to install visual studio code update как исправить
  • Failed to install the hcmon driver vmware как исправить