Re-flash boot loader on un-responsive 4200

LPWAN Modules / EVBs RAK4200
#1

Issue: Was downloading firmware created with RUI, download froze, module on EVB now unresponsive

Setup: RAK4200 EVB, serial port, Windows 7 etc etc

Using the exact same cable, computer and firmware I’ve updated another RAK4200 EVB, twice, with the original firmware I’d created and an update with a bit more debug printf and it’s all good.

What is the procedure for re-flashing the whole module? The docs say contact support.

PS, very excited about getting RUI going, lots of potential for simple sensor devices!

#2

Please tell me you E-mail.
I will send your document about burn the firmware.
:smile: :smile: :smile:

#3

Seems like this is something that should be part of the routine documentation and not a special request? I’d definitely want to know what the path was before considering using this module…

#4

Since bootloader does not support self-burning, users need to use other tools unless they upgrade a new bootloader or erase everything.

#5

Of course, but SWD probes are fairly common.

Not having a published way to recover from a fairly possible situation is a real oversight in the product documentation.

1 Like
#6

Found a few minutes to re-flash the bootloader - which sadly didn’t allow me to program it. Compared the boot loader I downloaded from the site with a known good 4200 on EVB and it was the same. But still no joy in the serial download.

Took the mini-board off the EVB and I suspect the issue is that the plating on the tiny connector isn’t as well plated as it should be as it some of the ‘teeth’ are black rather than gold.

Tried bypassing the EVB with some connections to the serial port(s) but after an hour+ of messing about, lost the will to live. It still responds to the programmer so it’s not dead (yet) so at some point I’ll rework hot-air SMD the module off and look at it again, mostly as a curiosity.

At least I haven’t released the magic smoke.

#7

Did this re-flashing involve a full erase of the chip, or only of the bootloader sector(s)?

The initial problem report sounds very much like the flashing of the application failed partway through leaving the application sectors in an invalid state. If the bootloader isn’t doing a full CRC of the application but just seeing that there appears to be something there and branching to it, then if what is there isn’t functional enough to accept the command to get into bootloader mode…

In theory, it seems like it would be possible to reflash a bootloader that wasn’t a problem while leaving an incomplete application that was.

Any sense what criteria the bootloader uses to decide if there’s a valid application to start? Does the bootloader even have a fallback of going direct to download mode if there is no application?

#8

Hmm, good point, but the tiny pins on the tiny connector is still looking a bit beaten up under my magnifying glass.

I’ll have a stab at erasing the entire of the device and then put the boot loader back but Mr Pragmatic vs Mrs Timesheet vs Ms Academic-Interest will end up having a fight.

#9

Pressed buttons on the ST Link software to erase all the memory before downloading the boot loader - no improvement.