HALCOGEN 3.04 mibspiInit failed to reset mibSPI

Hi Dimitri,

As part of Startup MIBSPI Parity check , we bring the Module out of Reset. unfortunately we do not reset after the test.. We have fixed already and it will be part of next release, 

But this should not affect the normal operation of the module, Do you get any ESM error when you say it fails to operate?

Regards
Prathap 

Hi Prathap,

You are right. It is parity check related. Here is my steps:

I am trying to simulate spi-dma data movement with RM46 HDK. mibspi5 is looped back with external jumpers.

I took mibSPIDMA example and modified it for my need: 

There is HALCOGEN generated code for mibSPI5 only enabled.

1. mibSPI is configured in master multi buffer mode, word size 16bit, TG0 size 4, buffer mode 7, 

2. TG0 is triggered with tick timer, rising edge.

3.Two data pools are created: one for the transmitter, one for the receiver, transmitter data is generated   

4. Two DMA channels are set: 0 for the transmission pool, 1  for the receiver

5. Control blocks are set for frame size 4 (matching TG0 size)

6. Both of them are assigned for mibSPI  RX,TX request lines (30,31)

7. The last TG0 buffer (BUFID = 3) was assigned as trig for both DMA requests. A few frame transfer is set with icount

At this point  the first frame is loaded in TG0, rx is empty, status word is 0x8000. No parity errors detected.

8. TG0 enabled.

With standard mibspiinit no transmission happened. The TG is enabled and triggered. The TG flag register indicates TG0 is suspended.

There is a  tx parity error detected UERRSTAT = 1 in address   0 (UERRADDR0 = 0).

If I add  mibspiREG5->GCR0 = 0U  as the first step in  mibspiInit this parity error is not detected because UERRCTRL value is  5  even it was set to 0xA in init.  Why? It needs some time to reset mibspi regs?

I see my icount+1 transmissions with no data corruption.  But It looks like a hack. It works just because the parity check doesn't work. 

Why this parity error happened? 

Regards, Dmitri  

Hi Prathap,

I opened the spi parity memory in debugger  and I see it doesn't match data at all. It seems the memory was not updated because it shows 1111 state for all memory locations.

Regards, Dmitri. 

Hi Prathap,

In mibspi5ParityCheck(void)  located in sys_selftest.c  there is  a few lines like this:

/* disable parity test mode */
mibspiREG5->UERRCTRL |= 0U << 8U;

It doesn't  clean bit  8 as intended.  It does nothing indeed. 

This is why mibSPI comes with test mode enabled after parity check finished.

The same thing for mibspi3ParityCheck(void) and mibspi1ParityCheck(void).

Regards, Dmitri

Hi Prathap,

Yes there is parity error. And it looks like because of this my transmission stalls. That ever I do in HALCOGEN enabling or disabling  parity check even when UERRCTRL reads back 5 the transmission stalls. The only difference I see this parity error is not shown in UERRSTAT and ESTATUS1[0] if parity disabled.

If I reset mibspi myself without parity enabled all data are passing the loop without corruption. If I enable the parity it stalls as well right after TG0 is enabled.

I don't understand how this parity happened if there is no data mistakes? 

Regards, Dmitri.