2015-09-22 11:35 AM
Hello,
I'm having a strange problem that's been holding me up for the past few days. I've been trying to configure the FMC to work with a Cypress CY7C1051DV33 SRAM on a PCB that I developed. In fact, the configuration that I used worked, and I was able to read and write successfully. However, I noticed a small hiccup with the ST-Link debugger, and I always had to hit the go button twice whenever I initialized the FMC.
I didn't understand what was happening with the debugger, but I pressed on to work on some LCD code. At that point, I began to lose the connection with the debugger. I finally realized it was because the microcontroller went into a never-ending reset.
I got rid of the LCD code and pared out a few other things--the short story is I now had a piece of code that started up, turned on and LED, and initialized the FMC for SRAM. After some additional debugging I narrowed my problem down to the initialization of 3 particular I/O pins. At that point I suspected some hardware problem and reworked a few traces on the PCB that I found thought might be problematic (but skeptical that this would have anything to do with the reset).
To simplify things, I commented out most of the FMC configuration and only configured one of my problem I/O pins. Now I have a fairly simple piece of code that lights up an LED and configures a single I/O pin with the alternate GPIO_AF12_FMC function (if I configure this pin without the alternate function, the reset never occurs). The config code is as follows:
void
HAL_SRAM_MspInit
(
SRAM_HandleTypeDef
*hsram)
{
GPIO_InitTypeDef
GPIO_Init_Structure;
__GPIOE_CLK_ENABLE();
GPIO_Init_Structure.
Mode
= GPIO_MODE_AF_PP;
GPIO_Init_Structure.
Pull
= GPIO_PULLUP;
GPIO_Init_Structure.
Speed
= GPIO_SPEED_LOW;
//GPIO_SPEED_HIGH;
GPIO_Init_Structure.
Alternate
=GPIO_AF12_FMC;
/* GPIOE configuration */
GPIO_Init_Structure.
Pin
= GPIO_PIN_0;
HAL_GPIO_Init
(GPIOE,&GPIO_Init_Structure);
}
When HAL_GPIO_Init is called it
sets
GPIOx->AFR[0]=
GPIO_AF12_FMC (i.e. 0x0C)
.
When I run this code on the STM32F429I-DISCO board the reset never occurs. I physically disconnected the PE0 pin from all circuits on both PCBs just to make sure that something physically wasn't causing the reset.
There's apparently some hardware difference. The discovery board uses the 429, my board uses the 439. The microcontroller is clocked from the internal oscillator. Power seems stable.
#stm32f4-fsmc-sram2015-09-22 12:53 PM
I'm not familiar with any errata related to this.
See if you can refine what the processor thinks is the source of the reset, this is SPL code you'll have to translate to HAL.if (RCC_GetFlagStatus(RCC_FLAG_SFTRST) != RESET)
puts(''Software Reset''); if (RCC_GetFlagStatus(RCC_FLAG_PORRST) != RESET) puts(''Power-On-Reset''); if (RCC_GetFlagStatus(RCC_FLAG_PINRST) != RESET) puts(''External Pin Reset''); if (RCC_GetFlagStatus(RCC_FLAG_IWDGRST) != RESET) puts(''Watchdog Reset''); if (RCC_GetFlagStatus(RCC_FLAG_WWDGRST) != RESET) puts(''Window Watchdog Reset''); if (RCC_GetFlagStatus(RCC_FLAG_LPWRRST) != RESET) puts(''Low Power Reset''); if (RCC_GetFlagStatus(RCC_FLAG_BORRST) != RESET) puts(''Brown-Out Reset''); RCC_ClearFlag(); // The flags cleared after use2015-09-22 01:56 PM
Hi Clive,
Thank you for getting back to me so quickly. It was my fault, I didn't have the embedded linear regulator turned on. I've now wired PDR_ON to VDD, and added capacitors at VCAP1 and VCAP2. I need to read more carefully about this feature, but I did read that the regulator powers the internal peripherals. Seems to be fixed.Thanks again!