TCAN4550-Q1: Problems writing to control register

Hi Mike,

mike f said:

In the above thread, Eric Schott said "It is possible an attempt to unlock the protected registers to fail the MCAN is busy during the request". Can someone elaborate?

I'm not completely sure, but Eric might have been referring to pending messages transmissions and that if there are any, they will be completed before the device will enter the initialization state.

I can't think of a reason for not being able to set the CCE bit when the INIT bit already equals 1 outside of a SPI related error.  Can you read the Status (0x000C) and Interrupt (0x0820) registers?

I know you have said the scratchpad register seems to be accessible, but do you have the ability to monitor the 4 SPI signals (nCS, SCLK, SDO, and SDI) on a logic analyzer or scope?  If so, I could review them for possible protocol or timing related errors.

Regards,

Jonathan

Status reads 0x08, which indicates "Internal Multiple transfer mode access in progress".

Interrupts register reads 0x100000 which indicates "Power on".

Does that tell you anything?

I could get a logic analyzer going but not super easily. I'd like to check other avenues first. My feeling is that SPI is working correctly. I am very confident in the reads, but I had to swap the endianness to make them work correctly. I'm not certain about the writes just yet, though the scratchpad test was successful.

Hi Mike,

Understood, we can try to work without a logic analyzer.

The Status register value of 0x08 is normal and bit 3 is just a read only status bit saying there is internal access going on in the device which is common with a functioning device.  This is not an indication of any type of fault.  Other bits in this register would indicate some form of error with the SPI communication.

Just for clarity, the SPI interface uses a FIFO to handle the clock domain frequency boundary crossing between the SPI clock and the Core clock supplied through the OSC1/2 pins.  The device will monitor the number of SCLK transitions to ensure there is an exact number of bits pushed into and out of the FIFO and flag any associated errors in this register and the SPIERR bit in the Interrupt register 0x0820.

I was curious to see if there were SPI Errors detected on your SPI Write functions because the device is supposed to discard those write transactions and preserve the previous register data from getting replaced by "potentially corrupted" data that came from a SPI transaction that generated an error.  This was one of the thoughts I had for why you couldn't write a new value to the CCE bit of the control register.

Are you able to clear the PWRON bit in the interrupt register?  For example, you can read the register to see the PWRON bit is set, then write a 1 to that register bit, and then read that register back to see if it has cleared, or any new bits have been set such as the SPIERR bit.  Ideally, the PWRON bit will clear and the SPIERR bit will not be set in the process.

If that works, then the SPI is likely working correctly.  You can also try to write and read data to the MRAM memory (starting with address 0x8000).  If all of that works, then the SPI is likely not the issue with the CCE bit issue.

Regards,

Jonathan

I tried writing both 0x100000 and 0x00 to the interrupt (0x0820) register and in both cases it doesn't change from 0x100000 when I read it back. Following this, the status register is still 0x08.

I am using TCAN_SPI_WRITE_32 from the TCAN SPI driver - the same function I am using to successfully modify the scratch pad.

Hi Mike,

Again, you should not have issues clearing the PWRON bit by just writing a 1 to that bit position in the register. 

Can you write and read back a new value to any register other than the scratchpad register?  For example, can you try to write to some of the bits in the modes of operation and pin configuration register (0x0800)?

Are you using one of TI's evaluation boards, or a board of your own design?

Regards,

Jonathan

Hi Mike,

No worries, I'm glad I could help and to hear everything is working now! 

Regards,

Jonathan