We have a bare-metal application (no Linux) that runs in "secure user" mode. The first access to the FELXCAN registers (a load) causes an abort. I have verified and the clocks are all set up properly, and memory mappings are all correct too.
I set a break-point on this problematic load instruction (which is the first access to the FLEXCAN peripheral). After the debugger hit the break-point, a single-step caused an abort of course. Then I rebooted the board and stopped on the same instruction again, manually changed the CPU mode to "secure system" through the JTAG debugger and then single-stepped, the load instruction executed correctly. This implied that "secure user" didn't have access to FLEXCAN.
Inspection of the CSU registers (CSU_CL0 in this case) showed that the value is set to 0x00330033, which according to the Security Reference Manual should permit RD+WR for secure user mode. The AIPSTZx_OPACx registers are all set to zero (and AIPSTZx_MPR gives access to all four masters), so the peripherals should not need supervisor privilege for access.
Out of curiosity, I performed two tests:
- Set CSU_CL0 to 0x00FF00FF to make it fully permissive (full RD+WR access in all modes), and accessing the register in secure user mode still caused a trap (wrong behaviour)
- Set CSU_CL0 to 0x00000000 to make it fully disallow access, and accessing the register even in secure system mode caused a trap (correct behaviour, proving that I am modifying the correct CSU register, and my modifications take effect)
Can anyone shed some light on this? To me it seems like a silicon errata, in which it doesn't allow access to FLEXCAN in secure user mode, no matter the security configuration. I'm have verified this on IMX6Q (SabreLite) and IMX6QPLUS (Nitrogen).
Thanks in advance.