initialize data flash during code flash programming?

I think I saw this asked previously but can't find it....

When programming a S5D9 using the RFP, one observes writing to the code flash followed by writing to the data flash.

How does one control what is written to data flash, i.e. how does one initialize the 64k data flash contents during programming of the device?

Our application uses the S5D9 to control hardware (RF amp, valves, indicators) while watching various signals (photodiode, powers, temperatures).  We have about 40 flash locations we would like to pre-load every time we program.  Over time the device code makes adjustments to these stored parameters (fine-tuning/optimization).  

There is device program code to initialize them (but would like that not be an option, a user could accidentally run it and wipe out adjusted values), and we have save/restore functions on the host PC interface but that's time-consuming.

Thanks!

  • RFP will program the flash with what ever is in the file provided to RFP. If you want some intial values in data flash, you will need to have those inital values in the file you provide to RFP, or there is the option to fill the flash with 0xFF.

  • this seems correct as RFP only allows you to point at one file for loading.  how does one add the initial flash values to the *.srec file?  i'd imagine it's a set of (address, data) entries but where?

  • A description of the S-Record file format can be found here :-

    https://en.wikipedia.org/wiki/SREC_(file_format)

    I see 2 possible methods to include the inital data flash values in the S-Record :-

    1) Have the inital data declared in the source file of the application at the desired location, so the build process genrates an S-Record file with the inital data flash values included.

    2) Post process the S-Record after the build process to add the data flash initial values, something like http://srecord.sourceforge.net/ can be used to manipulate an S-Record file to add constant data :-

    http://srecord.sourceforge.net/man/man1/srec_examples.html#INSERTING%20CONSTANT%20DATA

  • Excellent, Jeremy- that's sounds not difficult.  (For some reason I was thinking srec files were binary not ASCII.)

    I'll get this working and report back on specifics.  Thanks!

  • Well this is turning into a disaster....

    After carefully researching this, I wrote a S-record file as follows: S0 header, S3 data record, and S7 termination.  Note that unlike code flash which starts at 0000 0000h, data flash starts at 4010 0000h, so S3/S7 4-byte addressing was required (code flashing uses 3-byte addresses so S2/S8 records.)  Specifically:

    S00600004844521B

    S345401003FE2332205468697320697320612074657374212061626320313233(zeroes)E2

    S70500000000FA

    The address 4010 03FEh was used to write into data flash block 1022, 2nd to last (highest) location.  After a couple of checksum errors dutifully caught by RFP, this was the response indicating successful programming:

    Loading File (G:\Shared drives\Renesas\VS2\Release\VS2_test.srec) CRC-32 : F58025B0

    Target device : Renesas Synergy

    Connecting the tool
    Tool : COM port (COM9), Interface : 2 wire UART
    Connecting to the target device
    Setting the target device
    Communication speed : 115200bps
    Setting the target device

    Erasing the selected blocks
    [Code Flash 1] 0x00000000 - 0x001FFFFF size : 2.0 M
    [Data Flash 1] 0x40100000 - 0x4010FFFF size : 64 K

    Writing data to the target device
    [Data Flash 1] 0x401003FC - 0x4010043F size : 68

    Verifying data
    [Data Flash 1] 0x401003FC - 0x4010043F size : 68

    Disconnecting the tool
    Operation completed.

    It's reporting that it wrote 68 bytes to data flash (which should have been 64, another issue to resolve.)  The extra bytes are probably why it wrote to 4010 03FCh instead of 4010 03FEh as directed.

    Of course since RFP erased everything, no code was overwritten- this was expected as this was just a test to see if data flash could be written from S-record file before merging S-records with the program code S-records (which could a problem due to the 24 vs. 32 bit addressing).

    So decided to write the program code back into the device before moving to next step, and RFP presented with this:


    Loading File (G:\Shared drives\Renesas\VS2\Release\VS2_163.srec) CRC-32 : 54C23D5D

    Target device : Renesas Synergy

    Connecting the tool
    Error(E3000203): An error occurred while connecting to the tool.
    Operation failed.

    It's hard to envision how writing to data flash would corrupt code programming.  So...

    • is this expected?  is there something above the data flash that cause this?
    • since it won't connect the RFP can't erase everything.  is there another way to erase?





  • What you tried to do should work, I did the following :-

    1) Prgrammed a simple Blinky program into the Code flash

    2) Programmed your Data Flash S-record into the Data flash of the device using RFP, I changed the block settings of RFP for this stage, so only the Dataflash is erased (i.e. leave the code flash alone, so the Blinky program is still in the code flash).

    3) Changed the RFP configuration so it will only do the Verify operation, put the device back into boot mode, and run RFP again, it verifies the contents of the Dataflash against the data in the S-record.

    4) Change the mode pin to be pulled high, reset the board,  and the blinky code runs.

    To erase the device you have 2 options:-

    1) Does the JLink debugger still connect to the device? If so, you could use JLink commander to erase the flash using the "Erase" command.

    2) Use the debugger to send the ALeRASE command to erase the Code, Data and configuration areas :-

    /cfs-file/__key/communityserver-discussions-components-files/206/ALeRASE_5F00_JLINK.zip

  • the board has layout for JTAG- usually is DNP except for a emergency like this.   i think i have the components on-hand.

    i still don't understand the addressing and reporting it wrote 68 bytes.  using addresses with 4010 0000h offset:

    it was told to write to 03FEh, so with 64 (40h) data bytes should have ended at 043Eh

    but it wrote to 03FCh, says it wrote 68 (44h) bytes, ending at 043Fh.
    although 043Fh- 03FCh is 43h or 67 bytes.

    i'm sure some of this math is off by 1's here and there due to how addresses are discussed (i.e., is end address the last byte or points to the next byte after it).

  • The dataflash on the S5D9 can be programmed in 4/8/16 byte units (and erased in 64/128/256 byte units). 0x3FE is 2 byte aligned, so 2 bytes of padding is added at the beginning and 2 bytes at the end to be able to write the 64 bytes of data, when the start address is 2 byte aligned.

    EDIT :- 0x3FE is also not at the start of an erase block, this means 2 blocks will have to be erased in the data flash to program the 64 bytes of data and 4 bytes of padding.