MIPS32 port

ChibiOS public support forum for topics related to the micro-controllers based on MIPS32 cores.
Posts: 10
Joined: Tue Jun 25, 2013 5:43 pm

Re: MIPS32 port

Postby gera » Wed Jul 10, 2013 6:42 pm

hi dmytro,
the first fix in SPI was definitely a typo - it caused wrong offset for brg register so brg was always set to 0.
The second one (cnt-1) - I am not really sure. Here is the story:

1. first I tried to make it work with SPI EEPROM (microchip 25AA02)
- when brg was set to 0, it worked but returned wrong data because clock speed was too fast for the EEPROM.
- after I fixed the clock, it started to hang with active RX channel. I found that SPI transmits one byte less than requested so I commented out "-1".
- the EEPROM started to work OK on 1MHz clock.

Btw, it seems to me that the first transmit is forced only when there is no triggering event:
dma_lld.c, line 244:

if (!cfg->evt)
dchx->econ.set = 1 << DMA_CHAN_ECON_CFORCE;

however the SPI driver always enables events for both tx and rx dma channels:
spi_lld.c, line 350:

dmaChannelCfg ccfg = {
.fifownd = 1,
.evt = TRUE,
.eirq = cfg->rx_irq,

2. the second chip I tried was MRF24J40 which is capable of doing 10MHz. It did not work with DMA at all. The DMA always hung with some weird negative values in counter registers. Probably we must use SPI FIFO or something. Simple enabling the FIFO did not help though. I haven't dug any deeper.

My current goal is porting my MRF driver so I have temporarily given up on DMA and use polling.
Hopefully someone sometimes will have opportunity to return to this area.

Posts: 98
Joined: Sun Oct 07, 2012 11:49 am

Re: MIPS32 port

Postby Dmytro » Wed Jul 10, 2013 11:22 pm

Hi gera,
I agree about the BRG register offset. I forgot to account the size of BUF register ... I was just very lucky that it worked for me.
So this correction was pushed.

Regarding the "forced transmission". When DMA is used I force the first transmission by writing into BUF register, not by setting CFORCE bit in ECON register:

Code: Select all

if (spid->config->dmad && spid->cnt > 1) {
     if (spid->txptr)
      port->buf = *spid->txptr;
      port->buf = 0xFFFFFFFF;

In my testing CFORCE bit didn't start the transaction in couple with DMA. After googling for a while I've found out that I'm not the only one and I judged that there could be some HW issue.
That's why I decrement the size of TX data by one.
Here's a thread on microchip's forum: http://www.microchip.com/forums/tm.aspx ... e=1#713992

Maybe I did another stupid typo in the code.

I'll try to find some SPI slave around to debug this case.

Thanks for the findings!
~ dmytro

Posts: 10
Joined: Tue Jun 25, 2013 5:43 pm

Re: MIPS32 port

Postby gera » Thu Jul 11, 2013 12:43 am

I conducted some more experiments with SPI/DMA.
With tx->n = cnt; (in __spi_start_transaction) both EEPROM and MRF chips work fine in DMA mode with up to 5MHz SPI clock.
With tx->n = cnt-1; RX DMA hangs, on the scope I see that SPI transmitted 1 byte less than expected.

By the way I have noticed another -1 in the __spi_dma_complete. Don't know if it must be removed too.

The MRF running on 10MHz gives me somewhat weird result on DMA.
Normally I see 8-pulse bursts on the SCK line, the picture is very similar in both polled and dma modes.
With 10MHz clock, the polled mode works fine and gives me the similar 8-pulse bursts.
DMA however results in one 8-pulse burst followed by a long contiguous burst which always
contains 8 pulses more than expected. The TX DMA channel hangs in BUSY state so is RX.
Both CPU and MRF data on the SDI/SDO lines are correct.

Hope this is helpful. Let me know if I can try some other experiments for you.

Posts: 98
Joined: Sun Oct 07, 2012 11:49 am

Re: MIPS32 port

Postby Dmytro » Thu Jul 11, 2013 1:56 am

there's -1 in __spi_dma_complete for the same reason as in __spi_start_transaction: almost same sequence for next DMA block as initially in __spi_start_transaction.
It's weird that when you remove '-1' you don't have extra SPI transmission in the end of whole SPI transaction.
The logic behind this algorithm is:
write first word of TX buffer to initiate transaction
SPI RX irq triggers DMA RX channel and normally then should trigger DMA TX
potentially there might be a race condition inside: TX DMA channel may start before RX DMA channel but to be honest I don't remember precisely the priority scheme

So, since first byte is sent manually(w/o involving DMA) __spi_start_transaction programs TX DMA transaction with cnt-1.

~ dmytro

Posts: 199
Joined: Sun Nov 06, 2011 3:54 pm

Re: MIPS32 port

Postby pito » Fri Jul 12, 2013 7:56 pm

There is quite long Errata doc (DS80000480N) for the pic32mx795.. We applied one gem from the list already @retrobsd.

Return to “MIPS32 Support”

Who is online

Users browsing this forum: No registered users and 3 guests