I think I accidentally overwrote my Arduino's bootloader when flashing using an external tool (probe-rs). Uploading sketches from the IDE fails with "No device found on ttyACM0" and double tapping the reset button does not cause the builtin LED to pulse.
I looked for options to recover and this article recommending the pyocd tool, but this fails with the message "flash init timed out".
I remember seeing a page on the Arduino site (or maybe in a Arduino git repository) that talked about flashing the bootloader using the 6-pin header next to the microcontroller, but I can't seem to find it anymore. Does anyone know where this is or an alternative method I can use to reinstall the bootloader? I have the hex file ready to go.
Unfortunately, when I try using the tool recommended in these threads it just says that the board is not responding. The person in the second thread found success with "ST-Link" and an "SWD Programmer", but I'm not familiar with these tools. I'll try shorting boot to ground and see if that helps when I have time and post back here.
If you already have the bootloader just flash it using whatever tool (openocd, pyOcd, probe-rs, whatever). If you don't have the bootloader download it from the Github repo linked above and then flash it. The R4 WiFi doesn't have a standard SWD header, but the R4 Minima should.
I believe so. But that's not the same as the Arduino bootloader. In particular, the built-in bootloader requires that the BOOT pin be grounded and a manual reset before it starts, while the Arduino bootloader can be started from the PC side of things...
Just flash the Arduino bootloader. You don't need to monkey with any pins. On the R4 WiFi the ESP32 acts as a CMSIS probe. On the R4 Minima you would need to connect an external probe like an STLink clone (the official ones are locked to ST hardware only) or BlackMagic Probe. From there just use your preferred tool (I've listed a few above).
USB/SCI boot mode is only an option if the UART (SCI) pins are made available on the Arduino headers or if you can actually access the USB port directly. Then you have to connect the whole mess to your computer and set up the Renesas flash tool. Not worth the effort compared to just using whatever generic flash tool you want.
I have UNO R4 WiFi. When do we need to GND the BOOT pin and pressing the RST button? While doing normal uploading a sketch, I do not do anything; the sketch just gets loaded and works.
To be clear the sort of recovery being talked about here is done outside of the Arduino IDE, generally from the command line. There's no need to fiddle with the pins and buttons on the Due or any of the R4s as they're bog standard ARM chips and work just fine with CMSIS-DAP (ARM's standard) debug probes and tools. The main use case for the USB/SCI boot mode is for boards that don't have the debug pins hooked up to anything.
The Uno R4 WiFi has an onboard USB debug probe in the form of that ESP32 . The others require an external CMSIS-DAP probe and cable like a knockoff STLink V2 that you can get from Adafruit or Aliexpress for a few bucks.
Install and configure whatever tool you'd like (left as an exercise for the reader) and then flash the Arduino bootloader.
pyocd flash -t r7fa4m1ab -e sector -a 0x0 /path/to/dfu_wifi.hex
This is the guide I was following when I got the "board is not responding" error.
The normal tools aren't working any more. As mentioned in my original post, PyOCD fails with "flash init timed out". Probe-rs tells me that it failed to load the flash algorithm into RAM:
Renesas calls it the "MD" pin and the Arduino schematics don't make it clear if it's actually hooked up to anything other than the ESP32 on the Uno WiFi. The peripheral used for SCI boot mode is only connected to the ESP32, and I'm not sure what it takes to configure it to pass the USB signals through.
It sounds like you probably nuked the option setting memory which could trash the initial clock configuration. You may be able to read out the OSM with probe-rs read or by attaching GDB to it, but it's likely you're in a difficult-to-impossible to recover state.
Also if you've zeroed out any of the option setting memory you're in a tough spot. The erase value is 0xFF, not zero so you would've had to explicitly write zeroes. Depending on what got zeroed out you may be able to issue an ALeRASE command but you'd have to hack up pyOCD or probe-rs.
I appreciate your counsel. Would you consider this a bug in probe-rs? It knows what chip I'm flashing so it should be able to know the maximum size that can be safely flashed. But I'm new to this so I'm not sure if overwriting the reserved sections might be a valid use-case if you know what you're doing.
I'm also a little confused as to why du reports the size of my binary as 32K, but stat reports 146,104 bytes which maths out to ~142K. I also used hexdump and the last address it reports is 23ab8, which again maths out to 142K.
I don't know what you tried to flash but I doubt there's a bug. If there were more than 32K of data to flash probe-rs wouldn't have begun writing anything. Most formats will have plenty of data that doesn't get written to the MCU.
probe-rs and pyOCD only write to the areas defined by the flash algorithm provided by Renesas. In the case of the RA4M1 the algorithm is fine but the option setting memory itself resides towards the beginning of the flash address space. On most other Renesas chips this is a separate area that you're not going to accidentally write to. This is something that both Arduino and Renesas should highlight more clearly but don't.
In the future if you're going to go around the Arduino bootloader make sure you're using something that uses the correct linker scripts.
I thought I did though. I looked at the memory map in chapter 4 of this document. It says the on-chip flash begins at address 0x0 and ends at address 0x40000, and the RAM begins at address 0x20000000 and ends at 0x20008000. From that I created the following memory.x file:
Did I misread the manual? It also says that "option-setting memory" begins at addresses 0x1010008 and 0x407FB1A0, which are nowhere near the regions I defined.
(I mispoke in my previous post, it was RAM that was 32k, flash memory is 256k.)
