Hi Experts
I am using NXP Mpc5748g, embedded with external flash AT25DF041B. Communication between controller and flash is done through SPI with DMA where Mpc5748g is configured as master and AT25 as slave in the application.
It is observed that when our application project is run without bootloader, communication between external flash and NXP is correct and every time we read and write correct data. But when we run our application with bootloader, communication is only normal for the first operation cycle and abnormal for the second, third, and so on operation cycle and we always fetch incorrect data. And if we remove the bootloader and reprogramming only the application, it will correctly read the last data in the AT25 when it is saved in normal operation cycle.
SPI waveforms have been captured and verified. They are always correct in both cases but actual data read and write from SPI is not correct at all when we use it with bootloader. There is no initialization of the specific SPI and DMA in bootloader.
Are there any experiences can be shared for this case? Is it possible for uninitialized RAM impacting on the SPI and DMA operation?
Please let me know what can be the possible reasons for that error.
Thanks
已解决! 转到解答。
Hi Faisal,
DMA and cache is the source of problem.
As mentioned in the reference manual, data cache coherency is not supported in hardware. It needs to be managed by software.
In short, cache memory is a feature of a core. DMA is another bus master on crossbar switch which is not aware of cache on a core. So, if DMA changes some data in RAM, the cache is NOT updated in this case. It's responsibility of user to either:
- configure such RAM area as cache inhibited by SMPU module. In my opinion, this is the best option. I highly recommend this for shared areas and for areas which are written by DMA.
- invalidate either whole cache or only some cache lines before accessing such data by core.
It's also possible to keep the data cache disabled but at the cost of lower performance.
Regards,
Lukas
Hi Faisal,
this kind of issues is usually (or rather always) caused by insufficient de-initialization. When jumping from bootloader to application, the best way is to reset the device and jump to the application right after reset based on some start condition. This could be implemented directly in the startup files.
Second option is to jump later from the bootloader. But in this case, I strongly recommend to put everything back to default reset state. The most important is to disable interrupt on all levels (by MSR[EE], by priorities in INTC, by local enable bit in a peripheral).
Regards,
Lukas
Hi Lukas,
Thanks for your reply. I have modified the startup code but still I have some ambiguities which are mentioned below.
We noticed that in the startup code of bootloader, "Invalidate and Enable the ICache and DCache" are executed, but not executed in application. If these statements are commented out in bootloader, the problem will be fixed and the application with bootloader can operate normally.
How can the initialization of ICache and DCache impacting on the SPI with DMA operations but seems no impact on other functions in our application?
I think this bug can be fixed in startup code of application. But if executing "Invalidate and Enable the ICache and DCache" statements in startup code of application, the bug still exist. How to understand ICache and DCache of z4204n3 core?
Best Regards
Faisal
Hi Faisal,
DMA and cache is the source of problem.
As mentioned in the reference manual, data cache coherency is not supported in hardware. It needs to be managed by software.
In short, cache memory is a feature of a core. DMA is another bus master on crossbar switch which is not aware of cache on a core. So, if DMA changes some data in RAM, the cache is NOT updated in this case. It's responsibility of user to either:
- configure such RAM area as cache inhibited by SMPU module. In my opinion, this is the best option. I highly recommend this for shared areas and for areas which are written by DMA.
- invalidate either whole cache or only some cache lines before accessing such data by core.
It's also possible to keep the data cache disabled but at the cost of lower performance.
Regards,
Lukas