RT1060 SDK DCP CRC32 problem

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

RT1060 SDK DCP CRC32 problem

2,108 Views
zhang2018tz
Contributor I

In RT1060 SDK DCP demo, the CRC32 testing (void TestCrc32(void))  runs OK. But after I copied the CRC32 related codes to my own project, void TestCrc32(void) fails in "TEST_ASSERT(memcmp(output, crc32, outLength) == 0);". i.e., the output is incorrect.

I also realized that if i disable data cache, then void TestCrc32(void) is good. However, after I moved the DCP output area to non-cahce area (the last 2 M of sdram), it still fails.

But I've seen some discussions here saying if DCP writes to non-cache places, it should work fine. 

Could anyone please help to check why my void TestCrc32(void) fails?

BTW, how can I confirm if an area is really no-cacheable? 

0 Kudos
Reply
5 Replies

1,987 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi zhang tz,

  About the cache details, you can refer to this application note at first:

https://www.nxp.com/docs/en/application-note/AN12042.pdf 

 About your DCP writes to non-cache places issue, what's the board you are using? MIMXRT1060?

  Can you upload your modified project which can reproduce the problem?

Kerry

 

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply

1,987 Views
zhang2018tz
Contributor I

thanks for your reply!

I am working on the NXP official RT1060 dev board. Attached is my project files.

Note 1: For easy checking the problem, I've made the board level files (baord.c,h, clock_config.c,h, pin_mux.c,h) all exactly the same as the DCP demo.

Note 2: in my testing code, I moved unsigned char output[4]; to noncacheble place: SDRam last 2M byte. It fails. If enabled the line "SCB_DisableDCache();" before going into the testing function, it will be successful.

Note 3: I modifed the memory map, i enlarged DTCM and ITCM to both 256K. I added the configuration codes for this.

再次感谢您的回复!

zhang2018tz

|

|

zhang2018tz@126.com

|

签名由网易邮箱大师定制

On 3/24/2020 13:57,kerryzhou<admin@community.nxp.com> wrote:

|

|

NXP Community

|

|

Re: RT1060 SDK DCP CRC32 problem

reply from Kerry Zhou in i.MX RT - View the full discussion

Hi zhang tz,

About the cache details, you can refer to this application note at first:

https://www.nxp.com/docs/en/application-note/AN12042.pdf

About your DCP writes to non-cache places issue, what's the board you are using? MIMXRT1060?

Can you upload your modified project which can reproduce the problem?

Kerry

0 Kudos
Reply

1,987 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi zhang tz

  Sorry for my later reply!

  Today, I test your project, can reproduce your problem, I also define your API in the internal RAM directly, but without the cache closed, the crc still not correct.

__RAMFUNC(RAM) void TestCrc32(void)

  In fact, the SDK DCP code also disable the cache.

   You mentioned:I've seen some discussions here saying if DCP writes to non-cache places, it should work fine. 

   Could you please give me the related link?  I also need to check it.

Kerry

 

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply

1,987 Views
zhang2018tz
Contributor I

Hi Kerry,

I have this problem fixed already. And I thought I replied in the forum. But today, after seeing your email, I went into the forum, and looked again, I didn't find my post last time. damn!

So, here is the explanation: (my unsuccessful posting last time)

I think I have this problem resolved. DCP functions in "fsl_dcp.c" use varables which are allocated in stack. In my program, stack is in OCRAM, which is cache enabled.

So, putting the crc32 calculation output data buffer into non-cache area is NOT enough, must make sure those temporary varables are also not cacheable. So, I forced those temporary varables to static, so that they go to DTCM. Then my testing code becomes successful.

The 2 temporary variables in fsl_dcp.c that I mentioned are: "dcp_work_packet_t dcpWork = "; and "dcp_hash_ctx_t hashCtx;"

Thanks again for any supports from anybody here!

zhang2018tz

|

|

zhang2018tz@126.com

|

签名由网易邮箱大师定制

On 4/10/2020 15:17,kerryzhou<admin@community.nxp.com> wrote:

|

|

NXP Community

|

|

Re: RT1060 SDK DCP CRC32 problem

reply from Kerry Zhou in i.MX RT - View the full discussion

Hi zhang tz

Sorry for my later reply!

Today, I test your project, can reproduce your problem, I also define your API in the internal RAM directly, but without the cache closed, the crc still not correct.

__RAMFUNC(RAM) void TestCrc32(void)

In fact, the SDK DCP code also disable the cache.

You mentioned:I've seen some discussions here saying if DCP writes to non-cache places, it should work fine.

Could you please give me the related link? I also need to check it.

Kerry

0 Kudos
Reply

1,987 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi zhang tz,

  Thanks so much for your solution sharing, and sorry for didn't find you already modify the stack location to the SDRAM.  It's better to put the stack and the heap in the internal RAM.

  If you have any other question in the future, welcome to create the new question post.

  

Kerry

 

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply