Part Number: TMS320F28388D
Other Parts Discussed in Thread: C2000WARE
While debugging a CM based CAN driver for F2838x, came across a strange issue. The basic Driverlib example DCAN code would corrupt the registers during the init module call. The issue seemed to be build dependent, as the original standalone C2000ware example worked, but the integrated version did not (on an EVM). All system aspects were checked (clocks, peripheral ownership passed to the M4, etc). But the code always corrupted the registers at the line below
void
CAN_initModule(uint32_t base)
{
//
// Check the arguments.
//
ASSERT(CAN_isBaseValid(base));
//
// Place CAN controller in init state, regardless of previous state. This
// will put controller in idle, and allow the message object RAM to be
// programmed.
// This write access to CAN_O_CTL corrupts the module registers!
HWREGH(base + CAN_O_CTL) |= ((uint16_t)CAN_CTL_INIT |
(uint16_t)CAN_INIT_PARITY_DISABLE);
//
// Initialize the message RAM before using it.
//
CAN_initRAM(base);
The build environment was modified to be almost identical to original C2000ware, but did not change the results.
Debugging from disassembly, the write access to CAN_O_CTL caused the corruption, with a pattern across that modules register set. For example, when writing 0x1401, the entire space would be
0x14011401 0x014011401 0x0140101401 ... or
0x00001401 0x00001401 x00001401 ... and I believe some other signatures
I did recall the module sync issue from the F2837x/C28 as posted here:
http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/577233
Changing the HWREGH to a HWREG (32-bit access) made this issue go away and clearly matched at the disassembly level where strh 16-bit writes would corrupt, but str 32-bit writes did not. Needing to prepare the driver for a deliverable, no further investigative actions where taken. The driver is now working, but with this needed change (HWREG vs HWREGH at highlighted line of code).
Can someone comment on the information in the above linked post and how this would affect the CM accessing CAN_O_CTL on the CM/F2838x?
Are there certain system prerequisites needed before this write? Which if not followed would produce the corruption signature?
This seemed to be the only register requiring this change, so aside from understanding this particular case, there is also concern for any other potential register access sync/alignment corner cases.
Was using C2000Ware 2.00.03.00. Did not try the latest 2.01.
-Eric
