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.

RM48x flash documentation and safety usage

Other Parts Discussed in Thread: RM48L952, HALCOGEN

Hello

I'm working in a project with RM48L952. We need to use the flash bank 1 and flash bank 7 to store data while the program is running. I don't want to use bank 7 with  EEPROM emulation, because I want the whole 64kb to be available to my application.

After reading the User Manual spnu503, I've realized there is a group of registers which are missing. The registers are mentioned in spna148 document (they are the FADDR, FPWRITE0, etc). Hence the questions:

1) Is the F021 flash API Safety certified? Can we use it for safety applications or it is unsafe? We need certified software (for TÜV-approval).

2) Is it safe to erase/write the bank 1 on-the-fly? As I didn't find the registers in the user's manual, it seems to be a non-safe feature to write to bank 1 (or 0), using those non documented registeres mentioned on spna148.

3) Is there a very well documented sequence of initialization of flash registers, without using the initialization function of F021 API (Fapi_initializeFlashBanks)?

Thanks,
Tiago

  • Hello:

    About your first question, F021 was developed meeting IEC61508/ISO26262 requirements. Compliance support package is available for this module as part oh HALCoGen CSP.

    I'll forward your other questions to one of our experts to provide some feedback.

    Regards,

    Enrique

  • Modifying the flash in bank 0 or bank 1 during run time is generally not supported. The Cortex R4 will speculate fetches within the ATCM space to improve performance. To avoid false ECC errors to the ESM, all of the flash in the ATCM space should have properly coded ECC. This generally precludes modification of flash in the ATCM space.

    The only supported methods of programming the RM48L952 device use the F021 API.

    Best regards,
    Bob Crosby 

  • Dear Bob

    Its been two years since I wrote the question and I didn't replied. Thanks for the answer, but anyway at that time we decided to not use the internal flash for our solution.

    Right now I'm evaluating this subject again, in order to use the RM42x internal flash (another product). I just like to make myself clear that we are just going to use Bank 7, so no problems about messing around with flash ECC with bank 0 or 1.

    We haven't aquired the SafeTI Compliance Support Package for HALCoGen, we are not using HALCoGen, and we are going to submit the product to SIL3 certification.

    Is there any documentation which could guide me to implement the full programming routines to use the Bank 7 by myself? It looks like there is no documentation about what I should do to initialize the peripheral. It all leads to use the F021 API, whose source code is not provided. I just want to be able to write two bytes to bank 7 in some special product configuration situation and to be able to read this during power up. That's all.

    Best regards,

    Tiago Dall'Agnol

  • No, there isn't any documentation provided beyond the TRM and the F021 Flash API. I have copied one of the safety specialist as he has dealt with other customers with a similar requirement. Unfortunately he is on business travel this week so please be patient for his reply.
  • Hi Bob

    Did you get any update about this subject?

    Best regards,
    Tiago
  • Hello Tiago,

    Note that there are no specific requirements in the IEC61508 standard regarding using certified software. What is required is to use software that is compliant with IEC61508. Our model for this is to develop the SW per the standard and then provide the collateral to our customers to use during assessment of their system application as evidence of compliance to the standard. The software is considered a component in this context and should not provide an obstacle to certification of your system.

    For the F021 library, we can provide both static and dynamic analysis reports as required by the standard. The reports and testing are performed utilizing tools that have gone through the rigor of the IEC61508 tool analysis and classification. I have not hear od any specific issues with this approach unless the end application is either military or aerospace in which cases, IEC61508 isn't typically used.

    If this model won't work for you, please let me know and we can take the discussion off line in order to discuss more specific needs and application specific requirements that you may not be able to disclose in the public light.