Hello,
Starting from the renesas flashloader examples, my company developped a bootloader with USB and Can capabilities. This bootloader works well, with a screen device. To build our applications, we have a 2nd project configured as it should be with the Bootloader parameters set, working with Guix Studio.
However we do have sometimes (about 1/3 or 1/4) an Error.
When flashing a new build of our application(s), the appstart will fail. the error returned is 713, (#define SSP_ERR_NO_FLASH_IMAGES ((ssp_err_t)713) ///< No images found in internal mcu flash).
The only way to make it work would be changing/removing an image in GuixStudio and rebuild the app. Then the new .srec->.bch generated would work.
The complete flash process returns success to every steps, only when the appstart is performed would the error be triggered.
Would someone know where this could be coming from?
Thanks for your help.
Note: The MCu is a synergy S7G2, the bootloader works with SSP1.2.1
Edit: I found this post which seems to be about the same issue (but no solution was foud there) :
renesasrulz.com/.../50643
Some uppdate on my issue: As i was trying to find where could this issue come from, i found that r_fl_mot_converter.py had several versions, with a change made at line 388 : elif bytes_between <= self.max_fill_space and (len(cur_buffer)/2) + bytes_between + 1 < self.max_data_size
By changing this +1 value with other values, the bootloader may accepts or not the new .bch generated.
After programming one .bch and reading the S7 memory, I did the same with a non working .bch and i found only a small block was different from the working BCH flash.
This bloc is written with the 2 last blocs of the BCH file. The only issue is that by printing the values extracted from those BCH blocs when in the flashloader, those values are good for both working and not working BCH.
This was also confirmed by reverting the process of converting the .srec file to .BCH. By going from .BCH to .SREC, the data files were the same from both working BCH and non working BCH.
So the answer seems to be there was an issue in our Flashloader pack, that was then fixed in later flashloader packs.