[malcolmrook]

Found the source of the problem.

I was initializing all the peripherals at the start of the program, including 3 uart ports.

Receive on all ports was interrupt driven with the callback capturing data byte by byte and writing to buffers which were set to 300 bytes with a counter and a data set flag.

I then initialized GPS and GSM modules before reading the user data.  Unfortunately at this point the main loop which would read the data set flags and process received data was not entered.

The result was that GPS module was sending out location messages, which were being buffered but not processed.

I had omitted to do a bounds check on the interrupt routine for the uart handling the GPS messages so it continued to buffer data beyond the 300 byte array size.

As it happened the address of the array put it as the last entry in ram.

The result was that it kept writing with no problems until it eventually hit the stack address with obviously unpredictable results.

It was a stupid mistake which I should never have made.

I found it while looking at all the global variables after I had hit the problem and saw the byte counter for the uart data received (uint16_t to handle byte count beyond 256) way beyond where it should have been.

I have now put in a trap to stop writing the uart buffer at its designated size .

All is now OK.

Sometimes just putting your problems down in writing can clear you head and start you thinking straight.

Many thanks to those who offered advice.

[malcolmrook]

An update.

I had already set a breakpoint immediately after the initialisation loop which is where I obtained the values given in my original post.

I have experienced some similar problems before when using large arrays but got round them by declaring them global.

The array variables are declared global and should fit within the RAM as build shows 37K used out of 80K.

I have not tried setting the data breakpoint, as suggested by Bazis, yet but will do.

MCU has 512K flash and 80K ram so FLASH length set in lds file as 480K (512K – 32K for bootloader) and SRAM set to 80K.

_estack address is 20014000 which is within the SRAM (20000000 – 20014140)

lds file is below

ENTRY(Reset_Handler)

MEMORY
{
FLASH (RX)  : ORIGIN = 0x08004000, LENGTH = 480K
SRAM (RWX)  : ORIGIN = 0x20000000, LENGTH = 80K
EEPROM (RX) : ORIGIN = 0x08080000, LENGTH = 16K
}

_estack = 0x20014000;

SECTIONS
{
.isr_vector :
{
. = ALIGN(4);
KEEP(*(.isr_vector))
. = ALIGN(4);
} > FLASH

.text :
{
. = ALIGN(4);
_stext = .;

*(.text)
*(.text*)
*(.rodata)
*(.rodata*)
*(.glue_7)
*(.glue_7t)
KEEP(*(.init))
KEEP(*(.fini))
. = ALIGN(4);
_etext = .;

} > FLASH

.ARM.extab :
{
. = ALIGN(4);
*(.ARM.extab)
*(.gnu.linkonce.armextab.*)
. = ALIGN(4);
} > FLASH

.exidx :
{
. = ALIGN(4);
PROVIDE(__exidx_start = .);
*(.ARM.exidx*)
. = ALIGN(4);
PROVIDE(__exidx_end = .);
} > FLASH

.ARM.attributes :
{
*(.ARM.attributes)
} > FLASH

.preinit_array :
{
PROVIDE(__preinit_array_start = .);
KEEP(*(.preinit_array*))
PROVIDE(__preinit_array_end = .);
} > FLASH

.init_array :
{
PROVIDE(__init_array_start = .);
KEEP(*(SORT(.init_array.*)))
KEEP(*(.init_array*))
PROVIDE(__init_array_end = .);
} > FLASH

.fini_array :
{
PROVIDE(__fini_array_start = .);
KEEP(*(.fini_array*))
KEEP(*(SORT(.fini_array.*)))
PROVIDE(__fini_array_end = .);
} > FLASH

. = ALIGN(4);
_sidata = .;

.data : AT(_sidata)
{
. = ALIGN(4);
_sdata = .;

PROVIDE(__data_start__ = _sdata);
*(.data)
*(.data*)
. = ALIGN(4);
_edata = .;

PROVIDE(__data_end__ = _edata);
} > SRAM

.bss :
{
. = ALIGN(4);
_sbss = .;

PROVIDE(__bss_start__ = _sbss);
*(.bss)
*(.bss*)
*(COMMON)
. = ALIGN(4);
_ebss = .;

PROVIDE(__bss_end__ = _ebss);
} > SRAM

PROVIDE(end = .);

}

Finally had to bite the bullet and downloaded full evaluation of Keil MDK 5.  Used exactly the same code for main.c and it works fine.  Only difference was the size of the bin file produced at 37K instead of  85K.  Surely VisualGDB should do better.  Downside of Keil is the price.  A single seat license will cost almost £1300 if I have to go down that route.

[malcolmrook]

I would prefer to use the Texane ST-Link debug option not OpenOCD.  Does your comment indicate that Texane ST-Link uses OpenOCD?

The lost variable values were discovered as GPRS modem messages should have been echoed on a serial port if a ‘debug mode’ flag was set. The flag was set when the variable was declared and no messages were received.   On debugging, I found that the first occasion the flag was checked it had lost its value unless I reset its value after the program start.  Further investigation showed all declared variable values were lost.

[malcolmrook]

Thanks

Certainly looks like damaged files.

Re-creating the project did not help.

I removed VisualGDB and reinstalled.

All is now OK.

[malcolmrook]

I found a workaround which is to read the date as well as the time. All is OK then.

ST have responded to the problem and declared it not to be a bug but a feature!
It is always necessary to read the date after reading time. My response to them is that the GetTime and GetDate calls should be replaced by a single GetDateTime call.

[malcolmrook]

Hi
Re post on RTC problem. This appears to be a bug.

PROBLEM:
RTC appears to stop after reading time. First read OK then subsequent reads only show the first read time.

To reproduce
Version: VisualGDB 4.2
MCU: STM32F405RG
CLK: HSE 16MHz crystal PLL to 160MHz
RTC: HSE DIV16

Workround:

Read date as well. GetDate after GetTime.

[Author]

Posts