TMS570LC4357: Strange data abort triggered by reading N2HET1 RAM in user level of MCU privileges

Jiri Dobry

Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

Could you describe list of the possible sources for "external" event for the MPU unit in ARM core?
We still have issue with "External" MPU event when CPU is in "user" mode.
With the "system" mode it works fine.

Instruction is simple 32bit read "ldr.w r1, [r3, #456] ; 0x1c8" and r3=0xFF460000

PCR allow full access without limit (for the test, and we check it)

We have MPU region with DRBAR=FF440000 DRSR=00000023 DRACR=00001300, but it cannot be problem because it is "external" signal, not MPU internal fault.

And it fail again and again with DFAR=FF4601C8 DFSR=00001008 (Sync ext./read/SD=1).

There is no reason for this behavior from our point of view.

I found similar issue https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/916063/tms570lc4357-data-abort-exception-after-software-reset/3397709?tisearch=e2e-sitesearch&keymatch=dfsr#3397709

Problem is that this topic was not describe connection between NHET MPU abort and SW_RESET flag on SYSESR register. And this topic is not possible to view fully (missing pictures, missing attachments).
And we don't use HalCoGen sources, but our startup code which clear SW_RESET flag properly.

PS: it is same issue as https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1020988/tms570lc4357-strange-data-abort-triggered-by-reading-n2het1-ram-in-user-level-of-mcu-privileges?tisearch=e2e-sitesearch&keymatch=dfsr#

over 4 years ago

0 QJ Wang over 4 years ago

TI__Guru**** 197706 points

Hi Jiri,

I will study it, and come back later today.

0 Jan Nárovec over 4 years ago in reply to QJ Wang

Intellectual 410 points

Hi, is there anything new regarding this issue?

0 Jiri Dobry over 4 years ago in reply to QJ Wang

Expert 1810 points

Any news?

0 QJ Wang over 3 years ago in reply to Jiri Dobry

TI__Guru**** 197706 points

Hi Jiri,

The MPU region for N2HET1/2 RAM memory region is configured in the HALCoGen code:

If mpu is enabled, the HET RAM can be accessed in user mode or privileged mode.

0 Jiri Dobry over 3 years ago in reply to QJ Wang

Expert 1810 points

No it don't help to us. Sorry.
I am absolutely sure, that our MPU setting is correct. This is our MPU full configuration valid when MPU throw exception readed back from MCU on exception trap code.

RGNR[0x0]: DRBAR=00000000 DRSR=0000F73F DRACR=00001100 shadow
RGNR[0x1]: DRBAR=08000000 DRSR=00000025 DRACR=00001203 intRAM ro
RGNR[0x2]: DRBAR=FF000000 DRSR=0000002F DRACR=00001200 peripherial ro
RGNR[0x3]: DRBAR=00000000 DRSR=00000000 DRACR=00000000
RGNR[0x4]: DRBAR=08000000 DRSR=00008021 DRACR=00001207 shared intRAM
RGNR[0x5]: DRBAR=08018000 DRSR=0000FF1D DRACR=00001203 shared end ovl
RGNR[0x6]: DRBAR=08000000 DRSR=0000801D DRACR=00001203 fw intRAM
RGNR[0x7]: DRBAR=00000000 DRSR=00000000 DRACR=00000000
RGNR[0x8]: DRBAR=08068000 DRSR=0000801D DRACR=00001303 ram1
RGNR[0x9]: DRBAR=FF440000 DRSR=00000023 DRACR=00001300 extra Mpu
RGNR[0xA]: DRBAR=FFF7B800 DRSR=00008811 DRACR=00001300 extra Mpu
RGNR[0xB]: DRBAR=64000000 DRSR=00000011 DRACR=00001300 extra Mpu
RGNR[0xC]: DRBAR=68000000 DRSR=00000011 DRACR=00001301 extra Mpu
RGNR[0xD]: DRBAR=08020000 DRSR=00000000 DRACR=00000003 stack protect
RGNR[0xE]: DRBAR=08025800 DRSR=0000F015 DRACR=00001303 stack
RGNR[0xF]: DRBAR=00000000 DRSR=0000002B DRACR=00000602 flash

And decoded line 0x9 is

  .drbar = 0xFF440000, /* FF440000 - FF47FFFF */
  .drsr = (U32)MPU_256_KB
        | (U32)mpuREGION_ENABLE,
  .dracr = (U32)MPU_PRIV_RW_USER_RW_NOEXEC /**< 0x1300u Alias no read/write in privileged mode, read/write in user mode and no execution */
        |  (U32)MPU_STRONGLYORDERED_SHAREABLE /**< 0x0000u Memory type strongly ordered and sharable */

And mainly this is not internal MPU error, but "external". I know only one one source of external MPU fault - PCR. But I am sure that we disable PCR completely

    pcrPtr->PMPROTCLR0 = U32_MAX;
    pcrPtr->PMPROTCLR0 = U32_MAX;
    pcrPtr->PPROTCLR0 = U32_MAX;
    pcrPtr->PPROTCLR1 = U32_MAX;
    pcrPtr->PPROTCLR2 = U32_MAX;

There some source of "external" MPU abort exclude PCR?
We know, that it is "external" from DFSR=00001008 (DFAR=FF4601C8)

Jiri

0 QJ Wang over 3 years ago in reply to Jiri Dobry

TI__Guru**** 197706 points

The "external" abort means the abort is not from MPU and CPU, and the fault occurs on the bus or the interconnect.

Arm-based microcontrollers

Arm-based microcontrollers forum

TMS570LC4357: Strange data abort triggered by reading N2HET1 RAM in user level of MCU privileges