• State TI Thinks Resolved
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 16 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TMS320F28075: DCSM secured code crashes with stack in secured zone!?

Frank Moldenhauer
Prodigy 50 points

Part Number: TMS320F28075

Hi experts,

I observe the following with my DCSM secured code, where all the RAM / CLA sectors
and most of the FLASH sectors are in zone 1, I have GRABSECT FFF5D5D5, GRABRAM 10005555.

I have
a) Bootware running both if locked / unlocked, stack in unsecured RAMM1
b) Firmware running if unlocked, crashes if locked, stack in secured RAMD0.

With some tricky debugging (compiled in jumps to wait loop in an unsecured sector)
I found out, that the crash seems to happen as soon as interrupts are enabled and occur.
(I cannot look into secured code to find out the details.)

My questions:
- Can you confirm the behaviour?
- What is the reason for the crash? Is it the stack location or are there other reasons?
- If I am right, why is it not documented in the DCSM chapter of the TRM (SPRUHM9D, 2.13)?
- Is there a possibility to have stack in secured RAM too?

Thanks & regards
Frank

  • 0
    TI__Mastermind 38893 points
    Hey Frank,
    Good find — I went and dug into the TRM and E2E threads on this and I think I can give you a more concrete answer.
    The crash is almost certainly SCCRESET — and here's why
    TRM section 3.3.7 (DCSM Safe Code Copy Reset / SCCRESET) explicitly states:
    "To prevent security breaches, interrupts must be disabled before calling these [secure copy/CRC ROM] functions. If a vector fetch occurs in a safe copy or CRC function, the DCSM triggers a reset."
    The SCCRESET behaves like a SYSRS, except it also resets the debug logic to deny attacker access. That's why you can't easily observe what's happening — by the time the device resets, your debug session is toast too.
    The key question: Is your PIE vector table in the same zone as your secure stack?
    This is what I'd check first. On the F28075, the PIE vector table lives in RAM. When an interrupt fires, the CPU fetches the vector from the PIE table. If the vector fetch itself — or the subsequent context save (PC/ST0 push to the stack in RAMD0) — triggers any interaction with the DCSM secure context, SCCRESET can fire. The DCSM documentation for the F2807x family confirms that "data reads and writes from secured memory are only allowed for code running from secured memory." If anything in the interrupt entry path crosses a zone boundary, you've got a problem.
    On the RAMM1 vs RAMD0 question
    Your bootware works because its stack is in RAMM1 — which is unsecured (not assigned to Zone 1 in your GRABRAM = 0x10005555 config). The firmware crashes with the stack in RAMD0 — which IS in Zone 1. The crash happening specifically at interrupt enable time is consistent with the PIE vector table or the interrupt service routine entry code being in a different security context than the stack.
    Practical things to check:
    1. Where is your PIE vector table allocated? It needs to be in Zone 1 (secured) or at minimum not crossing a zone boundary relative to where interrupts are being serviced from.
    2. Where does the ISR code itself live? If the ISR entry or any code it calls is running from unsecured memory while trying to push context to a secured stack in RAMD0, that's your zone mismatch.
    3. Check your RESC register right at boot (before things crash). If SCCRESETn is cleared, that confirms SCCRESET fired in a previous cycle.
    On whether stack-in-secure-RAM is supported at all
    Per the TRM's memory access rules: Zone-1-secured code has full R/W/X access to Zone-1 RAM. So a stack in RAMD0 should work — as long as everything touching that stack (ISR entry, context save, the ISR code itself) is also running from Zone-1-secured memory. The problem isn't the secured stack per se, it's zone coherence across the full interrupt entry path.
    On the documentation gap
    The SCCRESET note isn't in the DCSM chapter (§3.13) — it's in the resets chapter (§3.3.7). That's likely why you didn't catch it there.
    Hope this helps narrow it down.
    Best Regards,
    Zackary Fleenor