SimpleBLEPeripheral

Hi Priya,

So to summarize your post, you are
1. Using custom hardware with a different pinout than the reference design
2. Able to run SimpleBLEPeripheral(SBP) as expected on the CC2650DK
3. Not able to run SBP on your custom hardware
4. Your custom hardware is able to transmit advertising packets when using SmartRF studio

Please confirm above are correct.

To help you debug, I have a couple suggestions:
1. Have you update the board file used by the SBP project to include your new custom hardware? This is discussed in section 6.2 of the Software Developer's guide
2. If you have debug access to your part, can you verify that the processor is not caught in an exception when running SBP? You can do this by loading your software using your IDE and the pausing execution and examining the callstack

Sean--

Yes for 1-4.

Yes, the custom edited board file is being selected by SBP. It is not obvious

how SBP uses the custom board pins. Is the UART or SPI used by the SPB?

If so, where?

Here is a screen shot of the RTOS object view. It seems like ICallTaskEntry is constantly

running. What pins is this function using?

Thanks,

Priya

 

SPI is used to control the LCD and UART is not used in default simpleBLEPeripheral project.
in SimpleBLEPeripheral_init(void)
Board_openLCD() will be called when you have TI_DRIVERS_LCD_INCLUDED defined in defined symbols.
Then it will do SPI_open, which can be found in LCDDogm1286.c

You can try to just disable the predefined symbol TI_DRIVERS_LCD_INCLUDED, then the whole project should run without problem

Yes, the TI_DRIVERS_LCD_INCLUDED has been disabled. Which means SBP is not using
any of the pins from our custom board, is this correct? The project runs without a problem
on the 4x4 2650DK but not on the custom board.

SBP project will still try to access the pins when PIN_init is called in main.c
Can you step thru the program and see where it stops? Are you able to enter SimpleBLEPeripheral_init?
Can you also try to disable power_saving in your project and see if it runs?

Christin,
Thank you for your prompt reply. The program steps through each function call in main.
all the way until sys_bios(). Probing the IOC port sets on the scope is not showing
any action past the init routine. On the DK, you can see the advertising signals
on these ports. When the debug is halted, it always becomes stuck in a loop at address
"0x1001bbd6" . This seems within the stack boundary.

Regards,
Priya

This sounds more like a HW issue. smartRF studio only checkout the radio, but there are more to the device than just radio. Have you already tried to disable power saving? Can you post your schematic so that we can better assist you?

Have you checked out all the supply voltages?

processors.wiki.ti.com/.../CC26xx_HW_Troubleshooting

I posted the schematic on this discussion recently:
e2e.ti.com/.../1790308

Yes, I disabled power saving. The voltages on pin outputs are measuring correctly, these
were checked when the parts were mounted on the board. Not everything on the schematic
has been mounted, just the 2640, the external flash, the RF PA and the associated resistors
and caps.

Here is the pin init table matching the schematic:
PIN_Config BoardGpioInitTable[] = {

/* Button is active low */
Board_HGM_OUT | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL,
Board_PAEN_OUT | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL,
Board_EN_OUT | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL,

Board_ACSN | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL,

Board_UART_TX | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL, /* UART TX pin at inactive level */
Board_UART_RX | PIN_INPUT_EN | PIN_PULLUP | PIN_HYSTERESIS,

Board_SPI0_MISO | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL,
Board_SPI0_MOSI | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL,
Board_SPI0_CLK | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL,
Board_SPI0_CSN | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL,



PIN_TERMINATE /* Terminate list */
};


Here are the custom board.h definitions:
#define Board_LED_ON 1 /* LEDs on CC2650 are active high */
#define Board_LED_OFF 0
#define Board_LED1 PIN_UNASSIGNED
#define Board_LED2 PIN_UNASSIGNED
#define Board_LED3 IOID_5 /* RF1.2 */
#define Board_LED4 IOID_6 /* RF1.4 */
/* Button Board */
#define Board_KEY_SELECT IOID_7 /* RF1.14 */
#define Board_KEY_UP IOID_4 /* RF1.10 */
#define Board_KEY_DOWN IOID_3 /* RF1.12 */
#define Board_KEY_LEFT PIN_UNASSIGNED
#define Board_KEY_RIGHT PIN_UNASSIGNED
/* LCD Board */
#define Board_3V3_EN PIN_UNASSIGNED
#define Board_LCD_MODE PIN_UNASSIGNED
#define Board_LCD_RST PIN_UNASSIGNED
#define Board_LCD_CSN PIN_UNASSIGNED
/* UART Board */
#define Board_UART_RX IOID_1 /* RF1.7 */
#define Board_UART_TX IOID_2 /* RF1.9 */
#define Board_UART_CTS PIN_UNASSIGNED
#define Board_UART_RTS PIN_UNASSIGNED
/* SPI Board */
#define Board_SPI0_MISO IOID_0 /* RF1.20 */
#define Board_SPI0_MOSI IOID_9 /* RF1.18 */
#define Board_SPI0_CLK IOID_8 /* RF1.16 */
#define Board_SPI0_CSN IOID_7 /* RF1.14 */
#define Board_SPI1_MISO PIN_UNASSIGNED
#define Board_SPI1_MOSI PIN_UNASSIGNED
#define Board_SPI1_CLK PIN_UNASSIGNED
#define Board_SPI1_CSN PIN_UNASSIGNED

Thank you,
Priya

Christin-- the board.h I posted before was a file from the saved workspace. The correct board.h as being compiled by the custom board is as follows:

#define Board_LED_ON 1 /* LEDs on CC2650 are active high */
#define Board_LED_OFF 0
#define Board_LED1 PIN_UNASSIGNED
#define Board_LED2 PIN_UNASSIGNED


#define Board_ACSN IOID_7 /* RF1.14 */

#define Board_HGM_OUT IOID_0
#define Board_PAEN_OUT IOID_2
#define Board_EN_OUT IOID_1

#define Board_KEY_LEFT PIN_UNASSIGNED
#define Board_KEY_RIGHT PIN_UNASSIGNED
/* LCD Board */
#define Board_3V3_EN PIN_UNASSIGNED
#define Board_LCD_MODE PIN_UNASSIGNED
#define Board_LCD_RST PIN_UNASSIGNED
#define Board_LCD_CSN PIN_UNASSIGNED
/* UART Board */
#define Board_UART_RX IOID_9 /* RF1.7 */
#define Board_UART_TX IOID_8 /* RF1.9 */

#define Board_UART_CTS PIN_UNASSIGNED
#define Board_UART_RTS PIN_UNASSIGNED
/* SPI Board */

#define Board_SPI0_MISO IOID_3 /* RF1.20 */
#define Board_SPI0_MOSI IOID_6 /* RF1.18 */
#define Board_SPI0_CLK IOID_5 /* RF1.16 */
#define Board_SPI0_CSN IOID_4 /* RF1.14 */


#define Board_SPI1_MISO PIN_UNASSIGNED
#define Board_SPI1_MOSI PIN_UNASSIGNED
#define Board_SPI1_CLK PIN_UNASSIGNED
#define Board_SPI1_CSN PIN_UNASSIGNED

Can you check the power consumption on the board? And did you change the front end configuration in the project. Base on the comment Charlotte gave, I see that you are using 4ID, right?

I don't think this has anything to do with the pin mapping since you had no problem calling PIN_init. Can you try to run TI-RTOS Pin Standby example and see if you can program it successfully on your custom HW?

Yes, BLEUserConfig has been updated for the correct front end configuration.
Yes, we are using 4x4 package on the DK and on the custom board. I see a PIN
interrupt eg I will look at. Is there a way to view power consumption in CCS or does
it have to be measured on the board?
Thanks,
Priya

Hi Priya,

Power consumption must be measured on the board. You can get a simple average power reading using a multi meter, but this doesn't capture instantaneous power spikes.

We went ahead and verified the voltage levels on the board again. VDDR and DCOUPL are measuring
just what they are supposed to. The standby current is high, no where close to 1 uA with only BIOS_Start()
running in the firmware, its in the order of 6 mA. Which probably means the 32kHz oscillator isn't working like its
supposed to, but the device should still advertise in response to SBP. Any fresh perspectives are much appreciated.

Thanks,
Priya

Priya,

I would recommend flashing and testing a TI-RTOS only example such as the standby example that Christin suggested to ensure the RTOS is able to start without exception, etc. This will help us further debug.

Is there an RTOS example that doesn't use LED's? Our custom board has no LED's

and I'm not sure how the PIN interrupt eg will run on it.

Thanks,

Priya

 

Priya,

There is an empty example under driver examples and there is a hello example under kernel examples. Either should do the trick.

The custom board is now working through CCS as well! All along, the connector to the XDS200 debugger could connect in two ways and it got hooked the wrong way every time SPB run was tried. Until we flash programmed the hex files, we couldn't track it down to this seemingly small error. I appreciate all the insight and help.
Priya