Error writing data to flash (from target-download) - rp2040 #1985
Comments
|
Hi there, unfortunately the Cortex-Debug output isn't particularly useful to us in this case as it doesn't give a why, from BMD's side of things (BMD is unable to express to GDB where and why Flash programming went wrong). What would be useful to help us help you is: what version of the firmware are you running on your Black Pill? and if you run up BMDA as That latter part will connect to your Black Pill probe using the BMD remote protocol, and then have BMDA drive everything. It will be slower, but BMDA has complete diagnostics available and is the easiest way to access the log output generated for what's going on with a target. |
|
Sounds fair, but I don't know how to reproduce what cortex-debug is doing, I can load using gdb but that's all. I'll close as I can't help myself in this. I appreciate your efforts. |
|
So, I read GDB MI documentation, and been able to reproduce the way you need it the same commands cortex-debug did: Here is the GDB output: What I could understand is: |
|
How interesting! Yes, this is something unspecified going wrong at +0xc70 into Flash on latest The error reporting for the RP2040 Flash process is not amazing in part because the main body of work that's done takes place directly on the target itself via a stub that's loaded on during rp_flash_prepare(). We'll have a think on how we can improve that and get the stub and the control code to have a bit more information on what exactly is going wrong to improve diagnostics. |
|
The error happens when my code is running which in fact uses the second core. Anything I can do to help? |
|
Thank you for the extra information. That confirms our suspicion that there is some re-architecture of BMD required to allow us to express that multiple cores are ganged together, and that when we halt one of them we need to halt all of them for things like entering Flash mode. Given that the project dynamically discovers the part and all cores, this is going to be a bit tricky which is why we'd been trying to not have to do the change required, but you've given us a clear example of a configuration of a part where the only way to get the right behaviour and a successful Flash programming is to halt all cores. If you wanted to, you could look at how to add a member to the target structure for describing core cross-linking with a list of other targets that participate in being the same physical device that all need halting together; however we completely understand if you'd prefer to leave it with us and let us dig in. Note that any solution to this needs to factor in that a scan chain may have multiple physical devices on it each providing targets for debugging, possibly even of the same device (eg, having multiple LPC43xx's on the same JTAG scan chain), and so the cross-linking cannot just assume that all targets, or even all targets of the same part name, are part of the same SoC/MCU. |
I'm affraid that this is outside my area of knowledge. C is no problem, but the internals of the debugger that isn't. If you need any extra information, just let me know. Thank you again for your efforts. |
I'm using a F411CE probe with a rp2040 target in VSCode with Cortex-Debug extension.
When I first try to 'launch' the debugger, I get the error:
Failed to launch GDB: Error writing data to flash (from target-download)When I try again, it works as expected. I notice that the first run, the board is running, application wise. After the error, the CPU halts. That's why the second attempt works.
When the Program stops, when it works is in
frame={addr="0xfffffffe",func="<signal handler called>"}, when it fails is inframe={addr="0x10008e16",func="prvIdleTask"...., which is FreeRTOS.Am I missing something here?
Here is the Cortex-Debug full debug output with the error(Focus on last 30 lines or so):
Here is the Cortex-Debug full debug output the second attempt(No errors):
The text was updated successfully, but these errors were encountered: