My STM32H743VI Application Runs to a debug instruction in the start-up code
When I start my program from the uVision debugger the code runs to a debug instruction in the start-up code.
It requires three run push buttons to get it past the debug instruction. The program then works perfectly.
This problem only happens when I include a large AXI ram buffer for sqLite which I use for storing real-time data.
The variable is defined thus
/* Define Heap for sqlite */
#define SIZE_SQL_BUFF 0x00067000 /* 421,888 */
#define MIN_REQ_SQL_BUFF 1024
ALIGN_32BYTES(char sqlBuffArray[SIZE_SQL_BUFF] __attribute__((section("SQLITE_HEAP_MEM"))));The scatter file is:
; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************
LR_IROM1 0x08000000 0x001E0000 { ; load region size_region
ER_IROM1 0x08000000 0x001E0000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
.ANY (+RO)
.ANY (+XO)
}
;************************************************************
EXEC_REGION_ITCM 0x00000000 0x10000
{
stm32h7xx_it.o (+RO)
realTimeProcessing.o (+RO)
PLLControl.o (+RO)
compthresholdcontrol.o (+RO)
powerProc.o (+RO)
tasks.o (+RO)
; stats5MinRMS.o (+RO)
powerLog.o (+RO)
}
;************************************************************
CONST_ROM 0x081E0000 0x00020000
{
writeFlashConst.o (*)
}
;************************************************************
DTCM_RAM_STACK 0x20000000 0x00001000
{
.ANY (STACK)
}
;************************************************************
DTCM_MAIN 0x20001000 0x0001F000
{
; freertos.o (+RW +ZI)
realTimeProcessing.o (+RW +ZI)
powerProc.o (+RW +ZI)
; PLLControl.o (+RW +ZI)
compthresholdcontrol.o (+RW +ZI)
dac.o (+RW +ZI)
getgpssentencestr.o (+RW +ZI)
comp.o (+RW +ZI)
write_flash.o (+RW +ZI)
sqlite3.o (+RW +ZI)
; fatfs.o (+RW +ZI)
pllcontrol.o (+RW +ZI)
rtcclockcaltask.o (+RW +ZI)
calibrationtask.o (+RW +ZI)
trcstreamingrecorder.o (+RW +ZI)
stm32h7xx_hal_flash.o (+RW +ZI)
.ANY (+RW +ZI)
}
;*******************************************************************************************************************
;SRAM1 131,072 0x20000
RW_SPI2_DMA 0x30000000 0x00002000 ;
{
; spiCommsHandler.o (PMON_BOARD_SPI2_RX)
; spiCommsHandler.o (PMON_BOARD_SPI2_TX)
uartWiFi.o (WIFI_UART_RX)
uartWiFi.o (WIFI_UART_TX)
}
;************************************************************
;SRAM2 131,072 0x20000 0x30020000 to 0x30028000
ADC1_DMA_BUFF_1_SR2 0x30020000 0x0005DC0
{
realTimeProcessing.o (ADC1_DMA_1) ;3000 * 4 * 2 = 24000 => 0x5DC0
}
;************************************************************
;SRAM3 32,000 0x20000 0x30040000 to 0x30028000
ADC1_DMA_BUFF_2_SR3 0x30040000 0x00008000
{
realTimeProcessing.o (ADC1_DMA_2) ;3000 * 4 * 2 = 24000 => 0x5DC0
}
;************************************************************
RW_SRAM4_ADC3_DMA 0x38000000 0x00010000 ;
{
main.o (+RW +ZI)
main.o (ADC3_DMA)
rtcSyncPrepTask.o (UART2_RX_BUFF)
}
;************************************************************
;AXI SRAM 524,288 0x80000
RW_AXI_1 0x24000000 UNINIT 0x00067000
{
freertos.o (SQLITE_HEAP_MEM)
}
RW_AXI_2 0x24067000 0x00019000
{
powerLog.o (POWER_LOG)
.ANY (+RW +ZI)
}
;************************************************************
;SRAMBACKUP 4096 0x1000
BACKUP_SRAM 0x38800000 UNINIT 0x00001000 ; 4096
{
calibrationTask.o (ADC_CAL_BACKUPS)
}
}
;*************** EOF Copywrite C 2019 R J Garnett *************I have used scatter files like this in most of my projects and never have come across this problem.
As soon as I comment out the code that calls up the variable the thing works. Minus sqLite of course.
Any ideas?
I was going to publich this project on this site as it uses sqLite really well and I know a lot of people want to use sqLite, but are intimidated by the need to write the VFS to talk to fatFS and to get the whole thing to compile. The sqLite DB works really well with write ahead logging. It's robust against power failures causing data corruption and for simply saving data without running large select queries it is very fast.
Any hep on this would be greatly appresiated as I have spend a day and a half trying to unravel it.