I've been working on a project where I have two identical Nucleo boards each with an attached NRF24L01+.

This little project has been going very well, I've been gradually refactoring, rebuilding and retesting and using two debugger instances and had zero problems with this setup.

Each board is plugged into a USB slot on my desktop PC and I use VisualGDB with Visual Studio, the setup has been working robustly for months.

A few minutes ago I made some more refactoring changes and started a debug of the transmitter and then the receiver.

But the receiver acted very weird, it didn't seem to go normally and looked as if the code had catastrophically crashed, I assumed I had a nasty bug perhaps illegal pointers or something.

But now every time I try to start debugging the receiver it fails:



looking at that stub log:



This is the same result I get when I do a test of the debugger:



If I do the test on each board here's the result

Receiver:



Transmitter



Despite that Error seen there this is normal, the transmitter can be debugged fine.

I rebooted, connected the board to a different USB and so on, but it always fails.

It looks as if the board itself has changed, and I wonder if the firmware has somehow become corrupted - can that be checked? fixed?

Thanks

 

Just a guess as I don't have your hardware. Is there a bugger chip on the board that may have been corrupted? Typically, there is a separate controller ( 2nd STM MCU) or FPGA the provides the interface glue between the USB interface to the PC and the actual pins on the operational controller.

There is usually an emergency firmware recovery method for that glue chip.

 

Just a guess as I don't have your hardware. Is there a bugger chip on the board that may have been corrupted? Typically, there is a separate controller ( 2nd STM MCU) or FPGA the provides the interface glue between the USB interface to the PC and the actual pins on the operational controller.

There is usually an emergency firmware recovery method for that glue chip.

Yes these boards have that, I read that this can be snapped off too if people want to use a Nucleo for a "production" system:



Thanks.

 

I've searched the web quite a lot and for the life of me cannot find a clearly written step by step guide to reset this board. All I can find is obscure posts in the ST site or Stack Exchange but no clear definite step by step guide.

Example:



Connect what? recover what, how?

 

There's an app called Cube Programmer, going to grab that...

 

Cube installed and unsurprisingly it cannot connect to the board.

 

Odd, I tried option "Connect under reset" assuming that executing that with RESET pressed would somehow connect, that failed.

But now, when I try to connect "Normal" it behaves differently:



I don't really know what's going in here but I couldn't debug it still, from the debugger/IDE standpoint is fails as it did earlier.

As you can see in that info window, it repeats that line ending in ....090 over and over and over.

 

I can run two instances of CUBE programmer each can connect to each Nucleo, no idea why I'm able to connect to the failing board but this tool now can. I scan of the memory dump they display shows that the bottom end of memory differs, wonder if that means corruption or just a slightly different version of firmware...

Ah they are different versions: working board = V2J30M19 failing board = V2J33M25

 

You might just need to update or
Downgrade the firmware.

 

You might just need to update or
Downgrade the firmware.

OK I did that, wasn't too hard and the Cube Programmer app connected and updated the board fine with newest firmware.

But it hasn't fixed my debug problem, something is still preventing the debugger from connecting as it used to...

 

Resolved, the problem was the app itself, it was causing the debugger connection (ST-LINK or whatever its called) to misbehave. So I was able to do a full chip erase with the Cube Programmer and can now debug OK.

Need to rectify the bug of course but at least I know its my code and that it can be forcibly erased.

Thanks for assistance gentlemen.

 

Ahhhh



My code was buggy, I was accidentally using those pin numbers on port A but they should have been on port B.

 

Ahhhh

View attachment 347581

My code was buggy, I was accidentally using those pin numbers on port A but they should have been on port B.