Why POR & XRSn Bits Won't Clear in the RESC Register

Your code is correct, but the Boot-ROM clears these bits before your application ever runs — and then they get re-set to reflect the current reset state. This is a hardware/boot-ROM behavior specific to the F2837xD, not a bug in your code.

What's Happening

The TMS320F28375D Technical Reference Manual (SPRUHM8K) explicitly states:

"After a POR, the POR and XRSn bits in RESC are set. These bits are then cleared by the boot ROM." [1]

And for the POR bit specifically:

"This bit is cleared by the Boot-ROM. As such, this bit cannot be used by the application to determine a POR." [2]

The same applies to XRSn:

"The XRSn bit in the RESC register is set whenever XRS is driven low for any reason. This bit is then cleared by the boot ROM." [1]

So the sequence is:

1. Power-on occurs → hardware sets POR and XRSn bits (value = 0x3)
2. Boot-ROM executes → clears both bits
3. Boot-ROM completes → your application starts
4. By the time your code runs, the bits reflect the post-boot-ROM state

The value of 3 you're reading suggests the bits are being re-asserted or that the Boot-ROM clearing didn't behave as expected in your configuration. However, the datasheet is clear: your application cannot reliably use POR/XRSn bits because the Boot-ROM owns the clearing of these bits.

Register Definition Confirms Write-1-to-Clear

While the register is defined as R/W1C (write-1-to-clear) [2], the Boot-ROM's intervention means your application-level writes compete with the boot process's handling of these bits.

Hardware Limitation on F2837xD

This is a known architectural limitation. The newer F2838x devices added a dedicated RESCCLR register specifically to address this:

"A new Reset Cause Clear (RESCCLR) register has been added to clear the status in the Reset Cause (RESC) register." [3]

This enhancement exists precisely because the F2837xD (and similar prior devices) lacked a clean application-level mechanism to clear these bits.

Workaround

Since you cannot reliably clear or use POR/XRSn from application code on the F28375D:

• Read the RESC register once at startup and store the value in a software variable
• Use software flags to track whether you've already processed the reset cause
• Focus on other RESC bits (WDRSn, NMIWDRSn, etc.) which are not cleared by Boot-ROM and behave as expected with SysCtl_clearResetCause()

To help refine this further, it would be helpful to know:

• Whether your application needs to distinguish between POR and XRS for functional logic (if so, alternative detection methods may be needed)
• Whether you're using the standard TI Boot-ROM or a custom boot configuration
• Your C2000Ware/driverlib version, as implementation details may vary

1. TMS320F2837xD Technical Reference Manual - Reset Section
2. TMS320F2837xD Technical Reference Manual - RESC Register Field Descriptions
3. F2837x to F2838x Migration Guide