A useful hint when using the FSL library and in-circuit debugging on the RL78

Hello folks! Sometime ago, when I started playing around with the RL78 debugger I found a strange issue: I had an application that was writing on address 0xFC00 and the next addresses (block 63) of the flash memory of a R5F100AEA (a 30-pin RL78/G13 with 64kiB of flash and 4kiB of RAM). For my surprise, every time the application tried to write on the flash (by using the FSL library) the debug session was closed with an error and after a reset the application code within the microcontroller would not run anymore!

My first thought was that maybe the application code was getting erased by a wrong FSL’s erase command (maybe my code was erasing the wrong flash block), but that possibility was quickly put aside by examining the code: there was no error and the right block was being erased (block 63, from 0xFC00 to 0xFFFF).

After some verification and wanderings I realized that the suspect code (flash erase and write functions) were successfully executed while running the debugger step-by-step, but as soon as I issued a “run” command the application would fail and the E1 debugger would loose contact with the target.

Further investigation revealed that, strangely, there was some data stored starting from address 0xFE00! That was really strange and unexpected because I did not write anything there! I started to mistrust my linker configuration file and believed that maybe some piece of my code was being written onto that flash area. Again nothing suspect was found on the linker configuration file and even the map file did not show anything stored on that area!

I then ran a simulation session to verify if my application code wasn’t really using (for code storage) that flash area and figured out that the area was completely erased: all 1024 bytes of block 63 were on their erased state (0xFF).

I decided to comment about that strange issue with Felipe Torrezan, a Brazilian engineer working for Renesas and after some wanderings I told him about the data/code written on flash from address 0xFE00 and he said he believed they belong to the E1’s monitor code. Well, that information made a lot of sense! That would explain why the code was present on a debug session but absent on a simulation session! Would also explain the communication failure between the microcontroller and the E1 debugger, as the debugger monitor code was getting erased!

Further investigation led me to the document R20UT1994EJ0100 which details the connection between a target RL78 and the E1 debugger and also the resources used on the target MCU. Page 17 of the document shows the memory resources used by the E1’s monitor, the following figure was extracted from that document:

The figure above and also the text on page 18 warns the user about the fact that the top 256 or 512 bytes of flash must be reserved when using a debugger (both E1, E20 or TK)!

In my case, all I needed was changing the code (and the linker configuration file) to use page 62 instead of page 63 and all worked flawlessly!

So be warned: when using the RL78 with a debugger, don’t forget to consider the resources needed by the debugger! That includes the first 12 bytes of flash, the top 256 or 512 bytes of flash and up to 12 bytes of stack!

See you next time!