cancel
Showing results for 
Search instead for 
Did you mean: 

BlueNRG-MS SPI transaction on HW reset - unexpected response (AN4494)

VGros.3
Associate III

Hello,

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'm using an STEVAL-IDB005V1D board (with a BLUENRG-MS chip) and an NUCLEO-F446RE board to read SPI signals.

Here is the test procedure (page 5/32 of AN4494) :

A BlueNRG hardware reset, performed by the microcontroller, generates an ACI event with a sequence described below and shown in Figure 3. BlueNRG SPI transaction on HW reset:

  • 1. Release of hardware reset -> OK✔�?
  • 2. IRQ goes high to signal an event from BlueNRG (if this signal is not present, it means that the BlueNRG firmware for some reason is not running) -> OK✔�?
  • 3. The external microcontroller lowers CS to access the BlueNRG and read the event -> OK✔�?
  • 4. The microcontroller reads 5 bytes from SPI; they should be [02,7F,00,00,00] -> OK✔�?
  • 5. The external microcontroller, after raising the CS, lowers it again to access the BlueNRG and read the event -> OK✔�?
  • 6.The microcontroller reads 5 bytes from SPI and [02,7F,00,06,00] is expected, meaning 6 bytes to read -> OK✔�?
  • 7. The microcontroller reads 6 bytes from SPI and [04, FF, 03, 01, 00, 01] is expected -> ERROR�?��?
  • 8. The microcontroller raises the CS again 

Steps 1 to 6 are working. Data are correctly received. However step 7 does not work. I receive [255,255,255,255,255,255], MISO stays always HIGH. Furthermore, IRQ does not go low at the end.

Here are my signals :

0693W000007ZJsfQAG.pngHere are the expected signals (AN4494) :

0693W000007ZJwHQAW.pngAnd here is my SPI configuration

0693W000007ZJwvQAG.png 

Any idea ?

Thanks for reading,

Best regards,

Valentin

1 ACCEPTED SOLUTION

Accepted Solutions

Didn't you send anything to MOSI? That could be the cause.

Refer to below figure:0693W000007ZpPAQA0.png 

In the 5-byte SPI header, the 1st byte of MOSI CTRL byte, the information telling the slave (BlueNRG-MS) that the master (MCU) is going to issue a write operation (0x0A) or a read operation (0x0B).

The following 4 bytes are dummy and shall be all zeros.

In your case, you need to send 0x0B in CTRL byte, so that BlueNRG-MS knows to output its 6-byte data to be read. After the data is read and no more data in buffer, the IRQ signal shall be cleared automatically.

View solution in original post

7 REPLIES 7
Winfred LU
ST Employee

Could you please try to configure clock phase (CPHA) to 0, leading edge?

Hello Winfred, thanks for your answer.

Actually, we only can set CPHA to "1 Edge" or "2 Edge", so I decided to test with CPHA = 2 Edges.

0693W000007ZXpFQAW.pngUnfortunately, the datas read by the STM32 are the same :

  • 1st 5 bytes : 02, 7F, 00, 00, 00 ✔�?
  • 2nd 5 bytes : 02, 2F, 00, 06, 00 ✔�?
  • 3rd 6 bytes : 255, 255, 255, 255, 255, 255 �?��?

MISO stay high during the 3rd packets and the IRQ of the BlueNRG-MS stay HIGH.

0693W000007ZXr1QAG.png

VGros.3
Associate III

I saw in another thread (https://community.st.com/s/question/0D50X00009XkezqSAB/bluenrgms-irq) that they were some data on MOSI line when we read data from BluenNRG-MS :

0693W000007ZnQLQA0.pngI didn't see anything describing this MOSI data in the documentation.

In the case CPHA having options of 1 Edge and 2 Edge, "1 Edge" is what i meant for 0 edge -- the "out" side changes the data on the trailing edge of the preceding clock cycle, while the "in" side captures the data on the LEADING edge of the clock cycle. 

0693W000007ZpOqQAK.pngIt looks that your configurations were good.

The issue could be in protocol.

Didn't you send anything to MOSI? That could be the cause.

Refer to below figure:0693W000007ZpPAQA0.png 

In the 5-byte SPI header, the 1st byte of MOSI CTRL byte, the information telling the slave (BlueNRG-MS) that the master (MCU) is going to issue a write operation (0x0A) or a read operation (0x0B).

The following 4 bytes are dummy and shall be all zeros.

In your case, you need to send 0x0B in CTRL byte, so that BlueNRG-MS knows to output its 6-byte data to be read. After the data is read and no more data in buffer, the IRQ signal shall be cleared automatically.

Hello Winfred,

I guess this is the answer, thanks. I'll try this tomorrow.

I didn't find this figure in the documents.

Hello Winfred,

I confirm that your answer solved the problem. Thank you for your help.

Best regards,

Valentin