SPI SPIFFY2 MASTER TAG BMC20737 Only Xmits 7 bytes

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Using SPIFFY2 in Master mode on BMC20737 TAG board I am able to send several bytes (6 to 😎 and see my clock and data going out on the scope, but after about the seventh byte the SPI Xmit function hangs, no further transmits or traces are output, and after about 5 seconds the board resets and starts all over again.

I'm running at 1,000,000 speed and have tried all 4 SPI modes and various combinations of pull up, floating and pull down, and about anything I can try including delays between byte transfers.

Any ideas on what the problem could be?  I have heard references to a FIFO buffer with limit of 16 bytes, but I don't think I'm even halfway to that point when it hangs.  I'm using a modified version of the Heart Rate Monitor App that comes with the SDK.

Also, when I tried 2,000,000 speed I got some weird results in the data output trace... looked like the FF I sent was changed to a F0.  Need to experiment with this more to be sure it was the speed setting and not some other catastrophic failure.

Any suggestions are appreciated.

Thanks,

Eric

p.s. using a very recent SDK 2.1.something

0 Likes
1 Solution
Anonymous
Not applicable

First thing, when trying to bring up a serial interface, clock it down, way down.  You don't want to be fighting configuration issues in addition to any noise.  Having said that, it doesn't sound like that's your problem.   I would look at how you're trying to send the data.  It's likely that its sitting and spinning and the watchdog is kicking the hardware or maybe you're going into deep sleep and waking back up again.  Register for the hidoff callbacks and/or disable the watchdog to see if the behavior is different.

Try the simple stuff first -- follow the sample code from the SPIFFY2 Master Sample Code chapter in the Wiced smart hardware interface document.  Try to send one byte, one word, and then a larger block and verify via the scope that the data is going over the wire as you expect.  Set up the fine timer to send a byte at a time and see if you can sustain a prolonged sequence that way.

View solution in original post

2 Replies
Anonymous
Not applicable

First thing, when trying to bring up a serial interface, clock it down, way down.  You don't want to be fighting configuration issues in addition to any noise.  Having said that, it doesn't sound like that's your problem.   I would look at how you're trying to send the data.  It's likely that its sitting and spinning and the watchdog is kicking the hardware or maybe you're going into deep sleep and waking back up again.  Register for the hidoff callbacks and/or disable the watchdog to see if the behavior is different.

Try the simple stuff first -- follow the sample code from the SPIFFY2 Master Sample Code chapter in the Wiced smart hardware interface document.  Try to send one byte, one word, and then a larger block and verify via the scope that the data is going over the wire as you expect.  Set up the fine timer to send a byte at a time and see if you can sustain a prolonged sequence that way.

Anonymous
Not applicable

Thanks for the suggestions.  I'll give them a try..

I tried to run at 500,000 instead of 1000000 but I got some error and I guessed that it was not a valid SPI clock rate.  I can't find any documentation on what the minimum clock rate is but I can try some numbers and see what works.

register for hidoff callback and disable watchdog ... I'll have to do some research to figure out how... I'm not familiar with those but it sounds very plausible that maybe the thing is going to sleep on me before my data transmission is done.  not sure how all that works as I'm new to the Broadcom products and still on a steep learning curve.  The documentation is not all that I had hoped it would be and the source code is not exactly transparent either.

I used the sample code in the doc's as a basis for my app.  Nothing fancy, just configure and set GPIOs as needed and send bytes.  Later when things are working better I'll want to implement an interrupt service for the ADC readout, but for now I can just do it on a timer after allowing a delay for ADC sample conversion.

I like the idea of sending one byte at a time on a cyclic timer... not really how I want the app to work, but it's worth a try to get a handle on what the issue is.  I wonder if delaying my SPI startup might help, like if I am starting to configure it too soon and conflicting with some other (system level) initialization that is still going on.

Thanks again,

I'll post again when I have tried these things and have some results to report.

0 Likes