0

I am working on an embedded device which uses an Aurix TC234. My (AUTOSAR) software which runs on it needs to do some checks during startup at a specific ROM address range.

The data which has to be checked is not written during flashing my software hex file. That means the address range has to be written before my software is flashed on that device.

My worst case scenario: Someone forgets to flash that address range. My software is flashed and during startup that memory is accessed. In that case a trap occurs.

My question: Is there a safe way of checking that specific ROM address range if it was written or not? Is it possible to handle such kind of trap?

Ferhat
  • 471
  • 3
  • 9
  • 21
  • is there any reason to not add additional section that will cover required address range with default flash content ? and later write additional data ? – Blueman May 19 '16 at 21:15
  • @Blueman The order of flashing is fixed. First data has to be flashed and than the software. Default flash content in my software would overwrite correctly flashed additional data. I am not familiar with ECC corrections. Is it possible to influence ECC? Can I deactivate it for a specific address range in ROM? – Ferhat May 20 '16 at 03:38
  • I'm not familiar with exactly this version of micro and I wasn't working directly with traps, but as far as I remember TC27X and TC29X had possibility to correctly exit ECC traps and no possibility to disable ECC on define range or at all. It's hard to provide more detail as each released document by Infineon in confidential and I have access to it only in office. – Blueman May 20 '16 at 15:43
  • That sounds interesting. Could you give me some keywords about this controlled exiting? I will search them in the manual on Monday in office. – Ferhat May 20 '16 at 16:19

2 Answers2

2

After few checks, for TC29X flow with ECC error for ROM can be handled like below:

  • enable SMU alarms
  • catch ECC error in ISR from SMU
  • store flag in no init RAM area
  • SW reset must be called (no exit from trap for ECC)
  • in next startup check flag value

Hope this help and similar solution will be available on your micro.

Blueman
  • 781
  • 10
  • 13
0

I'm not familiar with the TC234, but I would be amazed if accessing unwritten flash on any embedded device would cause a trap. The only difference between written and unwritten flash should be that the latter should have all ones written (assuming the flash begins erased). You should be able to simply check your data block for all bytes being 0xFF.

On the off chance that you might have flash that was not initially erased, you can add a check field to your data block, perhaps containing a CRC value for the rest of the block. On start up, check the blocks contents against the CRC field.

Edit: if you are indeed getting a trap, I'd expect this is due to your code using the data in the block without first validating it, leading to something like using an invalid index into an array or a bad pointer. Answer retracted. See comments.

DoxyLover
  • 3,366
  • 1
  • 15
  • 19
  • My software is based on AUTOSAR. I need to check again who causes this trap. Do you have any experience with AUTOSAR? I am using a fixed memory address to access memory, which is definetly correct. – Ferhat May 19 '16 at 20:19
  • This Aurix family have whole RAM & ROM area ECC protected so access to not initialized area (not flashed in this context) will cause trap as @Ferhat described – Blueman May 19 '16 at 21:06
  • In that case, I stand corrected and retract my answer. I'll strike it out but leave it so these comments aren't lost. – DoxyLover May 19 '16 at 21:50
  • Good hint @Blueman. That could be the reason. Any idea to handle these ECC traps correctly? – Ferhat May 20 '16 at 03:30