This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM48L952: nowECC -f not changing output

Part Number: RM48L952
Other Parts Discussed in Thread: NOWECC, UNIFLASH

I am trying to add ECC values with nowECC to a firmware which is loaded using a custom bootloader. I suspect the -f flag does not work correctly. In my bootloader, it does not zero out the end of sections that do not end on a 64 bit boundary as UniFlash and CCS seem to, so I am using -f 0xFF to account for this. I have a 1 byte constant which is the last member of a .const section and is 4 bytes into the 8 byte chunk. When ECC validation is enabled, I get an exception when loading this value. I have found that the ECC values are the same whether or not I specify the -f flag. Can someone verify this functionality?

  • Let me provide more specific information.

    According to my map file, the two constant values that have ECC errors are these.
    00037df0 SCHEDULER_TICK_PERIOD_MICROSECONDS
    00037df4 APP_TASK_COUNT

    Here is the section they are in
    00037dec 00000009 userApp.obj (.const)


    The debugger shows that the value of SCHEDULER_TICK_PERIOD_MICROSECONDS 0x000003E8 and APP_TASK_COUNT is 0xFFFFFF05. If I flash with CCS, APP_TASK_COUNT would be 0x00000005.

    The debugger shows that the ECC value at address 0xF0406FBC is 0xF3977A33. This value doesn't seem to change whether or not i use the -f argument. I would expect that this would cause a change because APP_TASK_COUNT is at the end of a section that does not end on a 64 bit boundary.

    The nowECC version is 2.22 and the arguments I am passing it is -r4 -f021 16M_ADD -f 55 -a filepath -i filepath

  • Westin,

    0xFF is used as the default fill value for nowECC. You can see the difference if you choose a different fill value.
  • I found that -f affected some of the ECC values, but it didn't seem to lead to correct values in one particular place in my application. I cannot explain why that was, but I did find the linker's palign keyword which I think is a better solution anyways because it makes no assumptions about what the value will be once it is in flash.