If for some reason you get a NAK talking to the boot loader is the only recourse to reboot the STM32?

[KiptonM]

I am writing SW in python to eventually program the STM32G051K8 over the UART from a BeagleBone Black (BBB). For testing I am doing it from the PC with a TTL-232R-3V3-WE USB to TTL Serial adapter.

At the moment I am making routines for each command.

What I am discovering, is that if something happens and a command returns a NAK, all of the following commands return a NAK and there is no recovery other than a HW reset.

For me it is not a big, deal as long as I know that is how it is supposed to work.

Right now I have the Get Command, Get Version, and Get ID commands working. And I am having some issue with the Get Read command. But after I do, none of the other commands that were working now work, they always return a NAK, until I ground the reset pin. Then I send the 0x7F to reset the baudrate, and I can continue.

Is this how it is supposed to work? Like I said, if that is the case I can work around it. (right now the PC cannot automatically toggle the reset line, I have to do that manually, but the BBB will be able to.)

If that is not how it is supposed to work, what am I doing wrong and how can I get it working after a NAK without a HW reset?

[Tesla DeLorean]

Different commands have different expectations, and different byte counts they are looking to see, and usually a couple of check points along the way. I'd probably avoid sending in long streams of bytes for the commands.

I'd probably try to walk it out in an interactive mode, as a means to sensing what's happening, but it's would help to understand what exactly it's objecting too in the first place. If need be I'd use a debugger to understand what's going on in the ROM code.

First up make sure you're using an 8E1 (Even Parity) comms mode. Perhaps view the interaction via a logic analyzer or a fork a serial connection into something you can monitor. Might try 8E2 if it's perhaps an inter-symbol timing thing.

Now for sure you'll have issues if it misidentifies the baud rate, the 0x7F is a pattern for timing, it's is not received by the UART, but measured with a TIM. Check the report back timing with a scope. If it auto-baud's wrong, you have to reset and retry, and make sure the comms lines don't glitch initially.

[gregstm · Accepted solution]

I wrote my own UART downloader years ago (in Delphi) - and I have come to accept that I can only do things in a certain sequence otherwise I have to do a reset, or if I get an error I have to do a reset - and with the STM32L4 series I sometimes have to cycle the power before things work (a reset is not enough https://community.st.com/s/question/0D50X00009XkbIQSAZ/stm32l433-boot0-pin-state-ignored-after-loading-program ).

Because my downloader program was just a stepping stone to getting my micro projects done, I have not put enough effort into figuring out what is going on with the bootloader. I wish you luck with your endeavours, and if you make any discoveries please share them here. I have just come to accept that the bootloader is just a cantankerous piece of software to deal with.

[KiptonM]

That is what I am seeing, except I have not run into the power cycle requirement yet. Thanks for the response, I will proceed with the assumption if you get a NAK you must reset to continue.

[KiptonM]

Thanks. A number of commands are working. (Get, Get Version & Read Protection Status, and Get ID) So the 8E1 and baud rate are correct. I am getting a NAK on the read command as I am still debugging it. When a NAK happens it appears no other command will work (of the ones I know are working) until I do a HW reset.

That is what I am seeing, and I want to know if that is normal. If it is I can deal with it. If it is not, then what should I do to get the commands to work again without a reset?

It looks from gregstm that the reset is what he had to do also. So that is what I will go with.

[Tesla DeLorean]

Most recently I've been using the serial protocol on Murata LoRa modules on the Arduino MKR 1300 board (there's a github of their fw update code)

I can't say I've seen it fail or be intermittent, but it's not something I've soak tested.

The thing that's most finicky with the system bootloader is it seeing glitches on any of the interface pins (per AN2606) it's watching initially. For example you can't have GPS or MODEMs attached to pins it might use, and have them squawk or fiddle with the line states during the initial startup. Here it is for-sure a one-shot deal, and if it's got it wrong the reset is the way to do it over again.

That it gets lost mid-protocol, and then is irretrievably broken, that seems like a whole different class of issues.

When writing there are alignment and erased cell issues to contend with. You get one shot with the write.And you'd have to wind things back a lot to recover from that.

The supported commands should be enumerate by the loader, it decodes the commands, and it checks the memory address ranges, sizes and checksums