ROM testing

"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.

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.

If the CRC result is never changing, it would seem that the CRC operation is not occurring.

Also be careful with using breakpoints, if using software break in the memory range of the CRC computation, this would impact the result.  Ensure that only hardware break is used in this memory range.

I doubled checked the address of the break point, it is out of the tested range and it is also a hardware break point. However, even when I run the code without a break point, still getting the same result.

As this is special provided software, you likely need to submit a support ticket to get help.

Ok, i will mark this thread as a solved issue and reopen another thread. I would like to thank you for your kind support.

Regards

I meant to use the Submit a Support Ticket method, rather than opening a new ticket.

Understood, many thanks again.

Hello JimB,

it seems that i can't submit a ticket on the page you have suggested because they will not answer a question related to a technical support as in the note is written "Please note that we can only answer questions relating to log-in/access issues for the communities.
If your question is related to technical support, please post that question directly into the Community."

Regards

My bad, wrong link provided above. 

en-support.renesas.com/createticket

Many thanks dear