BlueNRG-M0A Issue with Bringing up the BlueNRG and BlueNRG-MS devices (AN4494)

[Leo_Houston]

I'm trying to follow the test procedure for BlueNRG-MS (SPI) indicated in the Bringing up the BlueNRG and BlueNRG-MS devices - Application note (AN4494).

I am using custom board (Microchip dsPIC33F) to talk to BlueNR-M0A.

SPI Setting: 625K baud rate, SPII mode 0.

Following the Test procedure on Page 5, I got correct packet from BlueNRG-M0A:

Step 4: I received [02,7F,00,00,00]

Step 6: I received [02,7F,00,06,00]

However, on Step 7, I always received [FF, FF, FF, FF, FF, FF].  Note: I sent CTRL byte 0x0B, followed by 4 dummy byte 0x00. 

I have checked codes again and again, have no idea where to look at.

Please help with this issue, and point out a direction.

Thanks.

Leo

[BarryWhit]

Do you keep CS asserted between step 6 and 7? CS is often used for "framing" in SPI protocols. It's not just for letting the device know when you're talking to it - it's part of the device-level protocol. So de-asserting CS after sending a command but without reading the device's response will, on some devices be treated as aborting the command and send the device back into an idle state. Then, when you reassert CS and immediately read the bytes, the device is just waiting for you to send a command and isn't itself sending anything, so you're just reading the MISO line being idle.

The Appnote is quite explicit about how the CS signal should behave, but you may have overlooked it's importance.

It's also common for high-level SPI libraries to gloss over this issue and to simply deassert CS silently after each API call. Double-check how the SPI library you're using handles this.

[Leo_Houston]

Thank you Barry for reply.

SC line did stay LOW on Step 6 and 7. Please refer to attached screenshot. CH3 is CS line.

Leo

[BarryWhit]

The AN4494 test procedure says the SPI transaction should be started in response to an event being signaled on IRQ after hardware reset, are you doing that?

There is something strange about Figure 3 in the appnote which shows what the transaction should look like.

Comparing the figure with the text description, the figure doesn't show a read of 6 bytes (step 7) being performed after step 6, instead the CS is immediately deasserted (step 8). Maybe the protocol requires that you DO blink CS between steps 6 and 7? I'm not sure. 

[Leo_Houston]

Hi Barry,

On Figure 3, if you compare the length between first reply and second reply, the last 6 bytes were read indeed. I think it was marked wrong on 6. Second reply.

Leo

[BarryWhit]

it's hard to tell, but I think you're right. In Figure 3, IRQ is held high until the 6 bytes are read. You should really add that line to your Logic analyzer and see what it's state looks like relative to the transaction you initiate.

I also notice that in figure 3, the SPI clock rate seems to be lower at around 350kbps, though I don't expect that's the issue here.

[Leo_Houston · Accepted solution]

A quick update on this issue:

I got it work. For my case, it seems a timing issue,  in Step 5, that is, raising the CS, lowers it again, I didn't keep the CS high long enough. So after raising the CS, added 100~150uS delay, and then lower the CS. By this way, I got correct response.

Thanks.

[BarryWhit]

Good job, glad to hear it. You should accept your own solution.

The "SPI characteristics" section of the datasheet says the CS high hold time is 10 t(clk), at 625kbps that's 16us.

I recommend you experiment with reducing the CS delay slightly below and then above this, just to make sure you've really identified the root cause. If the critical value matches (roughly, due to process variation) the datasheet, you can be confident you've figure out the real issue. In your application, you should of course keep using a value with plenty of safety margin, as you have already done.

[Leo_Houston]

Thanks Barry.

I didn't read through BlueNRG-MS datasheet, only BlueNRG-M0 datasheet. The CS HIGH hold time was set to 10uS when it failed. Then I set it to 100uS. I didn't try some values in the middle. I will try to reduce CS high hold time on Monday.

Thanks,

Leo

[BarryWhit]

You should also check if you get the same behavior (offering 6 bytes, which end up as ff) if you omit the CS toggle altogether. If the hypothesis is that the CS toggle was too quick to register, you'd expect that skipping it entirely would give you the same behavior. 

Off-hand, I wouldn't have expected a missing CS toggle to result in the behavior you described. But I guess it's actually undefined behavior so, maybe.