cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

Anonymous
Not applicable

Hello,

I'd like to use BCM920737 as a SPI slave configuration, following the example at apps/spi_comm_slave I can send and receive data.

However I have a question : when the chip has nothing to send and therefore TX fifo is empty, what gets sent over the MISO line ? is there any hardware guarantee of a well defined value ? usually other SPI hardware that I've used before guarantee that when a FIFO is empty the value 0x00 is sent. what is the case with BCM920737 ?

running apps/spi_comm_slave code as is and using a generic SPI master I can see garbage sent out on the MISO line when I didn't explicitly set something in the FIFO ? can you confirm that ?

using SDK ver. 2.2

Thanks,

Sheref Younan

0 Likes
1 Solution
Anonymous
Not applicable

Hello jamesle1​,

Yes, I still have this issue. however I we moved this support request to a different forum, we will follow it up there.

Thank you for your support !

Sheref

View solution in original post

0 Likes
5 Replies
Anonymous
Not applicable

Hello.

According to our developers, it should just send 0xFF.

Do you see this behavior?

James

0 Likes
Anonymous
Not applicable

Hi James,

No, what I see that it sends 0x00 (which is fine) PLUS an undefined byte or two in the beginning (which is what I'm trying to avoid).

so, suppose that the master pushes 5 bytes to BCM920737 acting as a slave, and theBCM920737 TX FIFO is empty.

This is a good example to what I would see: "0x61 0x00 0x00 0x00 0x00".

Where 0x61 is undefined byte, usually a byte that was put in the FIFO and sent before, that byte seems to be stuck so if the master pushes another 5 bytes and the TX FIFO is still empty I will see the same values again (0x61 0x00 0x00 0x00 0x00).

Steps to reproduce : simply run the SDK SPI slave example spi_comm_slave, connect it to a generic SPI master and after reboot make the master send anything to the app and see what you get.

Thanks,

Sheref

0 Likes
Anonymous
Not applicable

Hi jamesle1

any updates about that issue ? did you manage to reproduce same observation that I have ?

Thanks,

Sheref

0 Likes
Anonymous
Not applicable

Hello sheref.younan

Is this still an issue?

I'm sorry to say that I couldn't reproduce your observation.

If you are still having this issue, my only guess is that that first byte that you see, is the byte used by the spi_comm_slave app to represent the number of bytes in a transaction. Although if the TX FIFO was empty in order to begin, it should all just be HIGH.

Does this help?

James

0 Likes
Anonymous
Not applicable

Hello jamesle1​,

Yes, I still have this issue. however I we moved this support request to a different forum, we will follow it up there.

Thank you for your support !

Sheref

View solution in original post

0 Likes