ROM testing

Hi Renesas community,

I have question regarding the Test of ROM in RX65N MCU. I got the software package from renesas for testing(CPU, RAM and ROM) and I have noticed that the implementation of functions that is used to test the ROM are missing. After I read the (RX(v2/v3 core) Family Diagnostic Software pdf file, the below functions are used to test the ROM But I can't find the implementation of those functions.

void crcHwSetup(unsigned int crc)
uint16_t crcComputation(unsigned int checksumBegin, unsigned int checksumEnd, unsigned int crc, unsigned int incrMode)

More details:

MCU: R5F565NEDxFC

Toolchain: CC-RX

version: 2.08.01

IDE: e² studio

Parents
  • "I got the software package from renesas for testing(CPU, RAM and ROM)" - can you be more specific as to what exact package you are referring to above?  The Renesas document number (e.g. "r20ut4686") which can be found at the bottom of most pages of the document would be helpful.

  • Hello JimB,
    thank you for your reply and support. The document number is (R30UZ0108EJ0300).

  • I am not able to find this using the standard document search.

    https://www.renesas.com/us/en/search?keywords=R30UZ0108

    You mentioned that you got the software package from Renesas, may I ask how it was provided?  Can you attach the PDF document to this thread?

  • Hello JimB,
    well, I have submitted a request to get the software package over this site "https://info.renesas.com/ia-fusa-software-info-request" and it was sent by email. I have also attached the manual below. 
    r30uz0108ej0300-ccrx.pdf

    In addition, I have found the implementation of these functions as they are both implemented as "assembly code" but still could not test ROM successfully.

    Regards

  • OK so this software package was provided by special request, this is not something generally available for download.

    It looks like the ROM test is based on CRC.  Without the code it is more difficult to help, but in general with CRC the problems I have run into would be improper initial value, incorrect CRC method used, or incorrect options when generating the CRC by the external tool that results in mis-match with the device CRC calculation.

    I would recommend starting with a very small area of memory that can be more easily tested and verified for the CRC on both ends.  Once that is working you can expand the memory coverage to a more realistic range of an applications address space.

  • Thank you for your reply and suggestions.
    According to your suggestion, I started to test a small area of ROM and I did the following:

    This is the function that I implement to test the ROM

    /** Beschreibung der Funktion: Funktion zum Testen von ROM
    *
    * @param
    * @return error 1(ja), 0(nein)
    */
    uint8_t Run_ROMTest(Test *pObj)
    {
    uint8_t error = 0;
    
    if( error == 0 )
    {
    // checksum storage address
    uint16_t* checksum = (uint16_t*)0xFFFFC000;
    uint32_t type;
    uint32_t checksum_start;
    uint32_t checksum_stop;
    uint16_t crc_result;
    uint32_t crc_inc;
    
    // Polynomials (1 => CRC-16) (2 => CRC-CCITT)
    type = 2;
    crcHwSetup(type);
    
    crc_inc = 0;
    checksum_start = 0xFFFFE000;
    checksum_stop = 0xffffffff;
    crc_result = crcComputation(checksum_start, checksum_stop, type, crc_inc);
    
    if( crc_result != *checksum )
    {
    error = 1;
    
    error_handler();
    
    }
    
    }
    
    return error;
    
    }

    And here is the Linker initialization:



    Now, when I run the code using (CRC-CCITT type) and set a break point on ( if( crc_result != *checksum ) ) the result would be:
    *checksum = 65535 at address = 0xFFFFC000
    crc_result = 65535

    and when I change the type to ( CRC-16 ), I ended up with the values below
    *checksum = 65535 at address = 0xFFFFC000
    crc_result = 0

    according to the PDF "Page 44", the initial value of the checksum is as below:

    CRC signature is initialized to the value below:
    - CRC-16 : 0x0000
    - CRC-CCITT : 0xffff

    Further, whatever range of addresses I test, I ended up with the same result above.

    I am not sure whether the initialization of the Linker or the addresses that I use are wrong.

    Many thanks in advance for any support and advice.

Reply
  • Thank you for your reply and suggestions.
    According to your suggestion, I started to test a small area of ROM and I did the following:

    This is the function that I implement to test the ROM

    /** Beschreibung der Funktion: Funktion zum Testen von ROM
    *
    * @param
    * @return error 1(ja), 0(nein)
    */
    uint8_t Run_ROMTest(Test *pObj)
    {
    uint8_t error = 0;
    
    if( error == 0 )
    {
    // checksum storage address
    uint16_t* checksum = (uint16_t*)0xFFFFC000;
    uint32_t type;
    uint32_t checksum_start;
    uint32_t checksum_stop;
    uint16_t crc_result;
    uint32_t crc_inc;
    
    // Polynomials (1 => CRC-16) (2 => CRC-CCITT)
    type = 2;
    crcHwSetup(type);
    
    crc_inc = 0;
    checksum_start = 0xFFFFE000;
    checksum_stop = 0xffffffff;
    crc_result = crcComputation(checksum_start, checksum_stop, type, crc_inc);
    
    if( crc_result != *checksum )
    {
    error = 1;
    
    error_handler();
    
    }
    
    }
    
    return error;
    
    }

    And here is the Linker initialization:



    Now, when I run the code using (CRC-CCITT type) and set a break point on ( if( crc_result != *checksum ) ) the result would be:
    *checksum = 65535 at address = 0xFFFFC000
    crc_result = 65535

    and when I change the type to ( CRC-16 ), I ended up with the values below
    *checksum = 65535 at address = 0xFFFFC000
    crc_result = 0

    according to the PDF "Page 44", the initial value of the checksum is as below:

    CRC signature is initialized to the value below:
    - CRC-16 : 0x0000
    - CRC-CCITT : 0xffff

    Further, whatever range of addresses I test, I ended up with the same result above.

    I am not sure whether the initialization of the Linker or the addresses that I use are wrong.

    Many thanks in advance for any support and advice.

Children