EmbeddedRelated.com
Forums
Memfault Beyond the Launch

SPIWrite crash

Started by seecwriter June 21, 2011
I have SPI working on my RCM6700. But I have found that SPIWrite()
crashes when I have a buffer length of 128. I'm trying to write pages
in an EEPROM, and the page size is 128 bytes. If I change the length to
64 it works fine. I've looked through the SPIWrite source, but nothing
jumps out as an obvious error. There are a couple of infinite loops
where it waits for the SPI status to change. Maybe the hardware is being
overrun?
Is this a known issue, or is there a length limit I missed?
When I say crash, I mean it never returns and I can't halt the debugger.
I have to close the connection and recompile to target.

buf[130];
memset( buf, 0, sizeof(buf) );
SPIWrite( buf, 128 ); <-- CRASH

Steve
I've done some more testing on this issue.
First, I thought maybe the value of SPI_CLK_DIVISOR was affecting
SPIWrite. I had is set to 8, so I started increasing it. When I got
to a value of 13, all calls to SPIWrite crashed.

Next I created a test project that just called SPIWrite. But it
didn't crash, even with a buffer length of 128. But since an EEPROM
write takes 3 calls to SPIWrite, I duplicated that in my test project.
And sure enough, if SPI_CLK_DIVISOR is 13 or higher, the third call
to SPIWrite always crashes, no matter what the buffer length is.
And it crashes on the first pass through the loop. So it's not like
it loops for awhile before it finally crashes.

Here is my test project file:

I forgot to mention, that if I decrease SPI_CLK_DIVISOR to 6,
SPIWrite no longer crashes for the 128-byte buffer. At 8 it crashes,
but with 6 it works. Go figure!
> I forgot to mention, that if I decrease SPI_CLK_DIVISOR to 6,
> SPIWrite no longer crashes for the 128-byte buffer. At 8 it crashes,
> but with 6 it works. Go figure!

Could just be the debuuger having problems with your code doing long loops
without hitting RST 28's.

Try it with polling turned off. Or try it without tyhe debugger.
It's not a debugger issue. In fact, if enable debugging in the SPI library
the problem goes away.

I've contacted Digi/Rabbit tech support to see what they have to say
about it.

Steve
> It's not a debugger issue. In fact, if enable debugging in the SPI library
> the problem goes away. 

That would make sense. Since the SPI.lib is compiled without debugging, the
debugger will time out on its long function calls because there are no RST 28's
in the lib.

That is exactly what I referred to.

Did you turn off polling like I said?

Why would you use an SPI divisor greater than 0? Surely the chip can run faster
than the rabbit.
Yes.If I run with or without polling it still crashes.

According to comments in the source code a divisor
smaller than 5 can cause instability.And the compiler
gives you a warning for values less than 5.
PlusI have to set the SPI clock speed so it meets the
specs of the ADC/DACs that I'm using. They are not
as fast as the serial memories.

Steve
Rabbit tech support has confirmed a bug in the spi peripheral
of R6000. They are working on a library work-around.

Steve

Memfault Beyond the Launch