Initialisation change 19.1.3 to 20.3.2 Topic is solved

[steved]

Using gcc version: 10.3.1 on 32F767

I'm trying to track down a change introduced between 19.1.3 and 20.3.2 which results in a program loaded into QSPI memory from running.

The "launcher" for this program disables pretty much everything apart from clocks and QSPI and one UART, then passes control.
My QSPI program is then a reasonably normal Chibi program, but with a much-truncated hal_lld.c file, which doesn't set up clocks, and does less hardware setup, leaving the hardware as set up by the launcher.

On receiving control, my program prints a short message using a polled serial port (which indicates successful passing of control).
It then sets up HAL and Chibi in the normal way, with two serial ports and an I2C port.
A change between 19.1.3 and 20.3.2 causes the QSPI program to hang after this point (reasonably confident its "hang" rather than "crash").

From debugging using serial messages, (I haven't worked out how to use the debugger in this scenario yet!):
halInit() and chSysInit() run through with no obvious problems.
The various integrity checks available through chSysIntegrityCheckI() all pass
Tickless mode, and system tick is running, and at approximately the correct speed (10kHz tick).

It seems that I can run code for as long as I like as long as I don't call chThdSleepMilliseconds() or do anything else that provokes a thread swap.
All this is standard Chibi code; none of mine has started before the hangup, so just main and idle threads running.

If recompiled as a "normal" program, setting up hardware etc, the Chibi 21 version runs OK; from which I deduce that something doesn't get set up, or gets set up wrongly.

Perhaps a problem with task swapping, or maybe interrupts. So something else I need to enable.

Initially started the move with 21.11.3, then progressively moved back versions to confirm that the problem arose between 19.1.3 and 20.3.2
I've done some comparisons of files, notably in the rt directory, but quite a lot of changes and no obvious cause.

Using gcc version: 10.3.1 throughout.

Any thoughts on how to debug this, or where the problem might lie?

[Giovanni]

Hi,

Is the HAL LLD resetting the QSPI in halInit()? we recently added a switch to make HAL not do this (it is in repository, not release code).

Giovanni

[steved]

Definitely not! (And I have proved it, during debug).

I override hal_init() with my own routine which leaves out all the clock initialisation stuff and selectively resets peripherals; there has been no relevant change in the "official" hal_init.c between 19.1.3 and 21.11.3. (I declare hal_init.c as a weak symbol so I can override it; means hal_lld_backup_domain_init() needs to become global).

I also disable calls to stm32_gpio_init() and stm32_clock_init() in __early_init() in the board file.

And all this used to work with Chibi 19; I just moved the code forward, and needed to make minimal changes for it to compile.

Having the ability to prevent reset of QSPI is useful; do you think it would also be useful to not reprogram the clocks, or is the execution guaranteed to continue through stm32_clock_init() without hanging?

[Giovanni]

Disabling initialization is already possible STM32_NO_INIT=TRUE.

I don't see how a thread swap could cause that, it is just code after all. Could cache affect this? try enabling/disabling it.

Giovanni

[steved]

Disabling initialization is already possible STM32_NO_INIT=TRUE.

Although that doesn't skip GPIO initialisation; just clocks. (Not that it should make a difference - but I might try initialising the GPIO tomorrow).

I don't see how a thread swap could cause that, it is just code after all. Could cache affect this? try enabling/disabling it.
Giovanni

Nor do I! Its just that the problem occurs as soon I call chThdSleepMilliseconds(), or some other Chibi routine (e.g. starting a UART); a thread swap seems a likely cause. One hypothesis is that some timer or interrupt isn't being set up/enabled properly (virtual timers were reorganised quite a lot, although possibly no substantive change). Whatever the problem, its down to a change introduced after 19.1.3.
Memory cache is already disabled.

[Giovanni]

Could it be something as trivial as a stack overflow? the newer version could have an higher usage, context switch is where stacks reach their lowest usually (pushing all registers on switch).

Giovanni

[steved]

Could it be something as trivial as a stack overflow? the newer version could have an higher usage, context switch is where stacks reach their lowest usually (pushing all registers on switch).
Giovanni

Very much doubt it - I've already added 0x400 to what was probably a generous allocation of 0x1c00 to PROCESS_STACK_SIZE in the first place. Chibi in the early stages shouldn't need anything like that much. (I did find when moving another application to 21.11 that updated versions of Chibi and third party libraries libraries necessitated a bit more stack in places).
Or might the exceptions stack need some more memory?

[Giovanni]

PROCESS_STACK_SIZE is the main() function stack, do you have other threads? you should check those stacks. Also try to increase PORT_IDLE_THREAD_STACK_SIZE, the default was 16 in 20.3.x, later it was defaulted to 64.

Giovanni

[steved]

PROCESS_STACK_SIZE is the main() function stack, do you have other threads? you should check those stacks. Also try to increase PORT_IDLE_THREAD_STACK_SIZE, the default was 16 in 20.3.x, later it was defaulted to 64.
Giovanni

No other threads at all; all runs off main(). It's a relatively simple program, which makes this all the more perplexing.
PORT_IDLE_THREAD_STACK_SIZE hadn't been changed from the default in Chibi, which was 64 (for 21.11.3; still 16 for 20.3.2). I did increase it to 128, then 256, in the makefile (UDEFS += -DPORT_IDLE_THREAD_STACK_SIZE=256) with no effect. Tried both 21.11.3 and 20.3.2.


I've managed to do some assembly-level debugging, from which it appears that the program is indeed in the idle thread.

I've previously demonstrated to my satisfaction that the system tick is running; but that's off a hardware counter, IIRC. That the program doesn't come out of a delay suggests that virtual timers may not be working.

The main indicator of life is a string of messages out of a serial port, and that's not happening either. So maybe interrupts not fully disabled?

[steved]

Found it!

Interrupt initialisation was moved to hal_lld_init() - managed to miss the visual comparison initially (the only bit I couldn't use Winmerge for).