Need help running spi_comm_slave on dev kit BCM20737TAG

[Anonymous]

I received the new dev kit I am trying to run the spi_comm_slave application with and SPI connection to our Renesas board. The new dev kit has GPIO Headers that I am using to connect the SPI using P1 (MISO) P2 (CS) P3 (SCLK) P4 (MOSI) and P15(Flow Control).  The program runs but I am unable to get the flow control to output on header J8. I tried using P32, P13 for flow control with same result. The spi_comm_slave app uses P14, but there is no header available for this pin. Any ideas?

[MichaelF_56]

Please accept our apologies for the delayed response Stephan.

With regards to the development kit you are using, is it the older TAG2 (20732-based) or newer TAG3 (20737-based) board?

There is a picture of both here: BCM2073X Product Portfolio (Module and Evaluation Board Overview)

The newer board works with SDK 2.0.1 only while the older board works specifically with SDK 1.1.

The newer board brings out the GPIO to headers, so I'm thinking that you must be using it. Please confirm my assumption as this will help the team isolate the issue.

Regarding SPI on the module, there are 2.  SPIFFY1 (12MHz) shares pins with the onboard I2C-based EEPROM, so its essentially unavailable. I will assume therefore that you are trying to interface through GPIO (external header) to SPIFFY2, which is the 6MHz SPI.

According to the WICED Smart Interfaces document here: WICED™ Smart Hardware Interfaces

Your selection of GPIO pins represents a valid configuration (bottom line in the table below):

Note that these are logical pins represented/used by the firmware, not the physical pin numbers on the module.

Confirm which board you are using and we will work with the team to determine how to map that function to one of the pins on the header (if using TAG3).

[Anonymous]

Thanks for your reply.

It is the newer TAG 3 (20737) board and I am using SDK 2.0.1. I was able to get this to work with the TAG 2 board and SDK 1.1.0 a couple of months ago so I am familiar with the product.

I understand the logical pins vs physical pin numbers. The logical pins numbers are printed on the TAG 3 board and are also used in Figure 7 of BCM920737TAG-03 WICED Smart Tag Hardware User Manual. It is the flow control pin that I am having trouble with as seen from this code snippet from spi_common_salve.c.

// use GPIO P14 for output flow control

#define SPIFFY2_OUTPUT_FLOW_CTRL_PIN           14

#define SPIFFY2_OUTPUT_FLOW_CTRL_PORT       0

P14 is not available on a header so I tried using P15, P32, P11, P8 etc but I can not drive it high to signal the spi master.

[MichaelF_56]

I've asked the firmware team for an answer.  I will let you know what they come back with...

[Anonymous · Accepted solution]

Hello smckee,

It's good that you have experience with the TAG2 Board - I can get right to the point

With respect to the TAG003 Board here are some considerations:

1. SPI does not support flow control and so must be implemented in Firmware
2. The CS line can be used as FLOW_IN and any GPIO for FLOW_OUTwhen SPIFFY2 is configured as a slave
3. P15 is hooked up directly to Vbat for battery level monitoring on the tag board, so it cannot be used unless some traces are cut.
4. P32 and P33 are used to configure puart by default, so its possible that it is overriding it.
5. P8 and P33 are brought out to the same physical pin on the package and so won’t work.
6. P24 and P25 are free on the tag board, so you can try one of these?
7. The other option is to configure puart to use P24, P25 and then use P32 or P33 as flow out.

Please let me know if you need more clarification.

JT

[Anonymous]

Regarding the answer to 5. above (P8 and P33 are brought out to the same physical pin on the package and so won't work)...  After reading the documentation I was under the impression that when two ports are brought out to the same pin you can still use one of them but the other one must be DISABLE_INPUT and DISABLE_OUTPUT viat the GPIO API.  Is this not the case?  (In this case P33 is used for Puart and that is the real reason why you can't use P8 which it is paired with... correct? or no? ))

Regarding item number 6. above (P24 and P25 are free on the tag board, so you can try one of these).. I think I was able to get these to work, but there are no header pins for them, and I found they are on the bottom of the board and I could solder a wire to each of the TP solder blobs on the bottom of the board to get access to these. If there is a better way to get to P24 and P25 please let me know.)

Thanks,

[Anonymous]

Regarding number 7 above. (configure puart to use P24 and P25 and then use P32 or P33...)  This sounds like it should work, but then will it be the case that the trace function will stop working?  If the trace function uses P32 and P33 via the puart functionality then routing purart through P24 and P25 which are not connected to anything would block the puart function.  is that correct?

[MichaelF_56]

ble_trace_enable allows you to route traces to the interface where you want them to reside.

Setting ble_trace_enable = 0 instead will disable all debug messages.

Re: How can I use ble_trace() for application debug?