Hi all, hope all is well. I've been trying to learn the STM32 by creating a project for myself, and I am stuck on the bluetooth portion of things. I have watched videos, read documentation, etc, and I just don't know where I'm going wrong. I've been going on and off with this for a bit over a month now. Long post sorry.
Board: F746ZG
Bluetooth expansion board: IDB05A2
Software Pack: X-CUBE-BLE1-6.1.0 with Basic, Userboard and sample app SensorDemoBLESensor
I have the pins appropriately matched according to the document "Getting started with the STMicroelectronics X-CUBE-BLE1 software package for STM32CubeMX" for a 144 Pin Nucleo board. They are as follows:
PD8/PD9 = USART3_TX/RX respectively
PA5/6/7 = SPI1_SCK/MISO/MOSI respectively
PA3 = EXTI3
PC0 = CS
PF13 = RST
PC13 = User Button
PB7 = LD2 [Blue]
As I said I've been at this for a month and sometimes I'd just run across a different error but I'm back to the original one now. This is when I'm initializing, MX_BlueNRG_MS_Init();
In hci_tl.c, at this part
/* Initialize low level driver */
if (hciContext.io.Init) hciContext.io.Init(NULL);
if (hciContext.io.Reset) hciContext.io.Reset();
I would get this message.
1) Failed to execute MI command:
-var-create - * hci.Context.io.Reset
Error message from debugger back end:
-var-create: unable to create variable object
2) Unable to create variable object
3) Failed to execute MI command:
-data-evaluate-expression hci.Context.io.Reset
Error message from debugger back end:
No symbol "hci" in current context.
4) Failed to execute MI command:
-var-create - * hci.Context.io.Reset
Error message from debugger back end:
-var-create: unable to create variable objec
That was A MONTH ago. Now the most recent issue as of today is the following:
Again under hci_tl.c,
/* Initialize low level driver */
if (hciContext.io.Init) hciContext.io.Init(NULL);
if (hciContext.io.Reset) hciContext.io.Reset();
Line 2 works fine, but line 3 does not. I step into it with the debugger, going to hci_tl_interface.c at this part
int32_t HCI_TL_SPI_Reset(void)
{
// Deselect CS PIN for BlueNRG to avoid spurious commands
HAL_GPIO_WritePin(HCI_TL_SPI_CS_PORT, HCI_TL_SPI_CS_PIN, GPIO_PIN_SET);
HAL_GPIO_WritePin(HCI_TL_RST_PORT, HCI_TL_RST_PIN, GPIO_PIN_RESET);
HAL_Delay(5);
HAL_GPIO_WritePin(HCI_TL_RST_PORT, HCI_TL_RST_PIN, GPIO_PIN_SET);
HAL_Delay(5);
return 0;
}
On my scope, the pins do change to their values, but after this, I'm sent to the interrupt handler file stm32f7xx_it.c to this,
void EXTI3_IRQHandler(void)
{
/* USER CODE BEGIN EXTI3_IRQn 0 */
/* USER CODE END EXTI3_IRQn 0 */
HAL_EXTI_IRQHandler(&H_EXTI_3);
/* USER CODE BEGIN EXTI3_IRQn 1 */
/* USER CODE END EXTI3_IRQn 1 */
}
Then, the program hangs. That's it. When I had the IDB05A2 board not attached it gets past but just hangs in a later part of the program.
The thing that come to mind to me is in the documentation it states
"If a Nucleo 144 pin is used, to correctly set the SPI Clock on pin D13, the D3 pin and D13 pin of the Arduino connector on the expansion board must be bridged, though not every Nucleo 144 requires this". I looked into the datasheet and didn't see anything about this, so I figured it is not necessary. Later in the post I have a scope reading where I did have a clock signal, so.
Another thing that comes to mind is my IDB05A2 looks like it has some white residue on the backside connectors from the factory, and under the board where J1 was soldered, there's a lot of some white looking residue on the board going across traces.
I noticed today under app_bluenrg_ms.c, uint8_t bnrg_expansion_board was set to IDB04A1, so I switched it to IDB05A1 (because I did not see any definitions for mine, A2). It did not help.
Also I CANNOT use the VirtualCOM program to update the board. I assume the board already has something flashed to it from the factory, but even then I cannot update the board. Everytime I use the VirtualCOM program to use the flashupdater.jar, I get told this opening my COM port
"No motherboard detected. Please check the nucleo board is plugged in correctly, the VCOM application has been flashed, the ST-Link is the latest version".
No idea why, the NUCLEO board works just fine for me for other things. The ST-Link is working fine.
One last note. A few days ago, this reset problem was no longer existing and actually making it to the while(1) loop and getting to MX_BlueNRG_MS_Process(), and this was my oscilloscope readings on the SPI pins. MISO is at 0 with spikes on the rising AND falling edges of the SCLK.
https://imgur.com/a/V8ug0xZ
Yellow - SCLK, light blue - MISO, purple - MOSI, dark blue - CS.
I checked from the STM32 board and got the same signals as well, so it I'm guessing the residue isn't affecting the IDB05A2 pins at least.
Thank you for reading.
