2020-06-20 11:07 PM
Hi
I am using the STM32F407 discovery board. Yesterday evening, I tried to init the SPI1. Then something strange happened. I suddenly receive the error message "Fail to insert all hardware breakpoints: You may have requested too many hardware breakpoints/watchpoints".
Also, the LCD based on HD44780 was working perfectly fine outputting the correct text. Now the text is either appended with a 32 constantly, or the text is flickering. So instead of saying "Alex", it says "Alex32".
Source code and console output text are given below. Any idea? I am also a little bit confused about the ST Link voltage, which is 2.88V. Is it supposed to be that voltage or may I gotten myself a hardware error?
Source code:
#if !defined(__SOFT_FP__) && defined(__ARM_FP)
#warning "FPU is not initialized, but the project is compiling for an FPU. Please initialize the FPU before use."
#endif
#include "stm32f4xx.h"
void funcSPIInit();
void funcIntInit();
uint8_t RXvariable = 0;
uint8_t TXvariable = 100;
int main(void)
{
funcIntInit();
funcSPIInit();
for(;;)
{
//SPI1->DR = TXvariable;
}
}
void funcIntInit()
{
// Initializes the interrupt
__NVIC_EnableIRQ(SPI1_IRQn);
}
void funcSPIInit()
{
// Enable bus for SPI1
RCC->APB2ENR |= (1<<RCC_APB2ENR_SPI1EN_Pos); // SPI1 bus enable
// Enable bus for GPIOA
RCC->AHB1ENR |= (1<<RCC_AHB1ENR_GPIOAEN_Pos); // GPIOA bus enable
// Set GPIO to AF5
GPIOA->MODER |= (2 << GPIO_MODER_MODER4_Pos); // PA4 to AF
GPIOA->AFR[1] |= (0x5<<GPIO_AFRL_AFSEL4_Pos); // PA4 to AF5 [0101]: SPI1_NSS
GPIOA->OTYPER &= ~(1<<GPIO_OTYPER_OT4_Pos); // PA4 to Push pull output
GPIOA->PUPDR &= ~(0x3UL << GPIO_PUPDR_PUPD4_Pos); // PA4 no pull up_down resistor
GPIOA->OSPEEDR &= ~(0x3UL << GPIO_OSPEEDR_OSPEED4_Pos); // PA4 low speed
GPIOA->MODER |= (2 << GPIO_MODER_MODER5_Pos); // PA5 to AF
GPIOA->AFR[1] |= (0x5<<GPIO_AFRL_AFSEL5_Pos); // PA5 to AF5 [0101]: SPI1_SCK
GPIOA->OTYPER &= ~(1<<GPIO_OTYPER_OT5_Pos); // PA5 to Push pull output
GPIOA->PUPDR &= ~(0x3UL << GPIO_PUPDR_PUPD5_Pos); // PA5 no pull up_down resistor
GPIOA->OSPEEDR &= ~(0x3UL << GPIO_OSPEEDR_OSPEED5_Pos); // PA5 low speed
GPIOA->MODER |= (2 << GPIO_MODER_MODER6_Pos); // PA6 to AF
GPIOA->AFR[1] |= (0x5<<GPIO_AFRL_AFSEL6_Pos); // PA6 to AF5 [0101]: SPI1_MISO
GPIOA->OTYPER &= ~(1<<GPIO_OTYPER_OT6_Pos); // PA6 to Push pull output
GPIOA->PUPDR &= ~(0x3UL << GPIO_PUPDR_PUPD6_Pos); // PA6 no pull up_down resistor
GPIOA->OSPEEDR &= ~(0x3UL << GPIO_OSPEEDR_OSPEED6_Pos); // PA6 low speed
GPIOA->MODER |= (2 << GPIO_MODER_MODER7_Pos); // PA7 to AF
GPIOA->AFR[1] |= (0x5<<GPIO_AFRL_AFSEL7_Pos); // PA7 to AF5 [0101]: SPI1_MOSI
GPIOA->OTYPER &= ~(1<<GPIO_OTYPER_OT7_Pos); // PA7 to Push pull output
GPIOA->PUPDR &= ~(0x3UL << GPIO_PUPDR_PUPD7_Pos); // PA7 no pull up_down resistor
GPIOA->OSPEEDR &= ~(0x3UL << GPIO_OSPEEDR_OSPEED7_Pos); // PA7 low speed
// Configure SPI
SPI1->CR1 |= (0x7UL << SPI_CR1_BR_Pos); // Sets BR to 111. SPI runs with 16MHz/256=62.5kHz
SPI1->CR1 |= (1<<SPI_CR1_CPHA_Pos); // CPHA: 2nd clock transition
SPI1->CR1 |= (1<<SPI_CR1_CPOL_Pos); // CPOL: 0 when idle
SPI1->CR1 &= ~(1<<SPI_CR1_DFF_Pos); // 8bit
SPI1->CR1 &= ~(1<<SPI_CR1_LSBFIRST_Pos); // MSB first
SPI1->CR1 &= ~(1<<SPI_CR1_SSM_Pos); // Software slave management disabled
SPI1->CR2 &= ~(1<<SPI_CR2_FRF_Pos); // Motorola Mode
SPI1->CR1 |= (1<<SPI_CR1_MSTR_Pos); // Master configuration
SPI1->CR1 &= ~(1<<SPI_CR1_BIDIMODE_Pos); // Full duplex
SPI1->CR1 &= ~(1<<SPI_CR1_RXONLY_Pos); // Transmit and Receive
SPI1->CR2 |= (1<<SPI_CR2_TXEIE_Pos); // TX buffer empty interrupt request enabled
SPI1->CR2 |= (1<<SPI_CR2_RXNEIE_Pos); // RX buffer full interrupt request enabled
SPI1->CR1 |= (1<<SPI_CR1_SPE_Pos); // Peripheral enabled
}
void SPI1_IRQHandler()
{
// We should read to and write from the buffer here?
}
This is the text from the console:
"
STMicroelectronics ST-LINK GDB server. Version 5.5.0
Copyright (c) 2019, STMicroelectronics. All rights reserved.
Starting server with the following options:
Persistent Mode : Disabled
Logging Level : 1
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
InitWhile : Enabled
Waiting for debugger connection...
Debugger connected
-------------------------------------------------------------------
STM32CubeProgrammer v2.4.0
-------------------------------------------------------------------
ST-LINK SN : 0671FF303431573457132556
ST-LINK FW : V2J36M26
Voltage : 2.88V
SWD freq : 4000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x413
Device name : STM32F405xx/F407xx/F415xx/F417xx
Flash size : 1 MBytes (default)
Device type : MCU
Device CPU : Cortex-M4
Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a13704.srec
File : ST-LINK_GDB_server_a13704.srec
Size : 1272 Bytes
Address : 0x08000000
Erasing memory corresponding to segment 0:
Erasing internal memory sector 0
Download in Progress:
File download complete
Time elapsed during download operation: 00:00:00.676
Verifying ...
Download verified successfully
handle_vCont_c, Failed continue thread
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Debugger connection lost.
Shutting down..."
Solved! Go to Solution.
2020-06-20 11:34 PM
GPIOA->AFR[1] |= (0x5<<GPIO_AFRL_AFSEL6_Pos); // PA6 to AF5 [0101]: SPI1_MISO
AFR[1] is the AFRH register controlling the function mappings of pins PA8-PA15. So the debugger interface becomes misconfigured at this point.
2020-06-20 11:34 PM
GPIOA->AFR[1] |= (0x5<<GPIO_AFRL_AFSEL6_Pos); // PA6 to AF5 [0101]: SPI1_MISO
AFR[1] is the AFRH register controlling the function mappings of pins PA8-PA15. So the debugger interface becomes misconfigured at this point.
2020-06-21 12:31 AM
Whoooop whooop - you made my day berendi. You have my eternal gratitude.
This code snipped would probably be the last spot to look for the reason. I just confirmed that I need to pay more attention.
One question, though:
Now that I did misconfigure the debugger interface, is there any risk that I may have damaged any internal circuitry on the discovery board? I had an HD44780 LCD hanging on PD0, PD1, PD2, PD3, PD4 and PD5.
Although I did not run my LCD routines, the LCD flickers now and - as mentioned in the original thread - the displayed text is not entirely correct anymore.
Is there a possibility that any circuitry (either on the STM32 discovery board or on the LCD itself) became damaged due to this misconfiguration on my SPI?
This question is just to get an idea as of why the LCD is not working anymore as it used to.
Thank you,