Weird problems caused by improper FSMC configuration

wsmysyn

Weird problems caused by improper FSMC configuration [Copy link]

RT Background:Recently, I have been working on a test project that uses the FSMC of stm32 and FPGA communication to control the read and write of the FPGA by defining the read and write of two STM32 memory addresses and outputting system information through the serial port. Phenomenon:I found a strange problem during debugging. When the board is powered on for debugging, there is no problem downloading the program to the flash. As long as the board is powered off and powered on again, it will not run normally and there is no output from the serial port. It feels like the firmware is lost. Attempt: 1. I wrote a simple lighting program and removed all the others. It was found that the power on and off functions are normal. So it should not be a firmware loss problem. It feels like the program is dead somewhere or a hardware fault is triggered. However, during power on, after downloading the program again and resetting, or single-step debugging, no problem can be seen. Because it is normal. 2. I suspected that the boot settings might be wrong. In fact, it was not downloaded to the flash. According to the manual, I checked that there was no problem with boot0 giving 0 and boot1, so it should be downloaded to the flash. 3. I felt that there might be abnormal initialization of peripherals just after power on. So I initialized it twice and added a long delay before initialization, but it didn't solve the problem. It should not be this problem. 4. Later, I had to use the printf function (I just assumed that the serial port part should work) to output debugging information before and after each module to determine which module had a problem. After determining which module, I entered the module to see which submodule had a problem, and then located the error step by step. After the above steps, I found that it was the FSMC write operation that was fixed in the FSMC module, and it was the first time the write function was called. It would always be stuck in the statement that assigned a value to the DATA port. FPGA_DATA is defined as access to a storage address. At this step, I felt that the FSMC might have an error at this time, or the FSMC was stuck, causing it to be unable to come out. 5. I went to find the initialization of the FSMC, and modifying the timing and mode had no effect. Later, I carefully checked the members of the FSMC initialization structure and counted them. There were 15 members in the structure. I initialized 12 of them. Two of them were either-or. So I was still missing two members. I initialized the other two parameters according to the timing requirements. A magical thing happened. It was OK and it didn't get stuck. Later, I verified that the two parameters were indispensable. Summary: 1. The reason for the problem may be that the default values of the two uninitialized parameters are uncertain. Re-powering on may cause problems with the FSMC configuration and enter the wrong mode, so it is "stuck". 2. Be sure to initialize all the data in the structure. The default value you think may not be what you think. 3. Don't copy other people's code casually. Be sure to understand it. . . Supplementary test: Print out the two settings of burst and Async in the FSMC configuration function, comment out the front and do not set

1. printf("bust : -> %08X\r\n", FSMC_NORSRAMInitStructure.FSMC_BurstAccessMode); printf("async : -> %08X\r\n", FSMC_NORSRAMInitStructure.FSMC_AsynchronousWait);

复制代码

Reset directly without powering off, the serial port prints: burst : -> 00000000 async : -> 00000000 Power off and then power on, the serial port prints: burst : -> F7DFFFFD async : -> F7DFFFFD or burst : -> F7FFFFFD async : -> F7FFFFFD It can be seen that it is indeed because after powering on again, the uninitialized variable is an abnormal value, and the FSMC register configuration is various parameters or operations. Therefore, the FSMC is configured in abnormal mode after powering on again, which causes the FSMC to "get stuck". In summary, the problem is finally solved. It is a lesson learned. . .

1. FSMC_NORSRAMInitStructure.FSMC_Bank = FSMC_Bank1_NORSRAM1; //Referred to FSMC_NE1 FSMC_NORSRAMInitStructure.FSMC_MemoryType = FSMC_MemoryType_NOR; FSMC_NORSRAMInitStructure.FSMC_MemoryDataWidth = FSMC_MemoryDataWidth_16b; FSMC_NORSRAMInitStructure.FSMC_DataAddressMux = FSMC_DataAddressMux_Disable; FSMC_NORSRAMInitStructure.FSMC_WriteOperation = FSMC_WriteOperation_Enable; FSMC_NORSRAMInitStructure.FSMC_BurstAccessMode = FSMC_BurstAccessMode_Disable; FSMC_NORSRAMInitStructure.FSMC_AsynchronousWait = FSMC_AsynchronousWait_Enable; FSMC_NORSRAMInitStructure.FSMC_WaitSignalPolarity = FSMC_WaitSignalPolarity_Low; FSMC_NORSRAMInitStructure.FSMC_WaitSignalActive = FSMC_WaitSignalActive_BeforeWaitState; FSMC_NORSRAMInitStructure.FSMC_WaitSignal = FSMC_WaitSignal_Disable; FSMC_NORSRAMInitStructure.FSMC_WriteBurst = FSMC_WriteBurst_Disable; FSMC_NORSRAMInitStructure.FSMC_WrapMode = FSMC_WrapMode_Disable; FSMC_NORSRAMInitStructure.FSMC_ExtendedMode = FSMC_ExtendedMode_Disable; FSMC_NORSRAMInitStructure.FSMC_ReadWriteTimingStruct = &p; FSMC_NORSRAMInitStructure.FSMC_WriteTimingStruct = &p; FSMC_NORSRAMInit(&FSMC_NORSRAMInitStructure); FSMC_NORSRAMCmd(FSMC_Bank1_NORSRAM1, ENABLE); printf("bust : -> %08X\r\n", FSMC_NORSRAMInitStructure.FSMC_BurstAccessMode); printf("async : -> %08X\r\n",FSMC_NORSRAMInitStructure.FSMC_AsynchronousWait);

复制代码

ljj3166

cubeMX sneered

wsmysyn

ljj3166 posted on 2018-6-19 22:40 cubeMX sneered

I have never used it, always using keil's library functions. . . . .

ljchip

OK, thank you! I have the same problem, your method works!
In addition, I have used mx, but the library function is also very good. I like both methods and now use the library.