RAK4631 RUI3 on 19007, VScode with Arduino extensions.
I’m getting a lot of these lately. The loading is over USB, so BLE shouldn’t come into it at all.
Often I can get around the problem just by changing some trivial thing like the exact text inside a println(). I do this to force a change in the CRC for each block and it mostly works.
Does anyone know what the real issue is?
Trivially modified code to generate changed CRCs, different hardware in case a flash memory cell had died, but load failing in the exact same place with the same error.
I had this maybe one or two times before.
Not sure what the reason is.
Recovery was possible by chip erase and flash new bootloader/softdevice with JLink or DAPlink.
I soldered the headers on and am working through that now.
I think I replaced the bootloader using WisCore_RAK4631_Board_Bootloader.hex and the JLink. I now have the slow green heartbeat and a peripheral that thinks it is a storage device. I still can’t get RAK4631-RUI3-V4.1.1-Flash-Dump.hex (that you sent me in April) to load through Ozone and JLink.
The device is now running Arduino Bootloader and Softdevice.
RAK4631-RUI3-V4.1.1-Flash-Dump.hex
Is for RUI3 and does not work with the Arduino Bootloader.
I’m moving over to the other thread. Sorry I created three of them that are kind of related.
That’s what I thought, but it’s been a long time since I was using the standard Arduino bootloader so I wasn’t sure.
Anyway, now that I have the Arduino bootloader I need to convert it back to RUI3. That’s what I thought the Flash Dump provided.
Back in April what I thought I did was open the RAK4631-RUI3-V4.1.1-Flash-Dump.hex in Ozone, set the processor to nRF52840 in the Jlink settings and click on
“Download and Reset”. This time around it is complaining that TDO is stuck high - which it is because the 4631 module doesn’t bring it out to the header, only SWDIO. But since TDO is only needed for trace it shouldn’t matter. I don’t recall this behaviour last time.
