Serial ports after bootloader has messed with them.

[rew]

I'm now booting from the bootloader into my application. After a few mishaps(*), this now works.... Sort of.

My serial communications are not working. I've added a " rccResetUSART1 ();" (and -2) to my code, but that doesn't change things. Something else is different from the state it is in after a normal reset.

Any ideas?

(*) For my cortex-m0, the interrupt table is fixed at address 0. The boot0 pin is wired "high" now, so that means the vector table of the bootloader is at address 0. ChibiOS starts. Takes the first interrupt... and BAM, you're in the "unexpected interrupt handler" of the bootloader.... syscfg->CFGR1 lower two bits should be set to zero.

[Giovanni]

It is not clear, does the vector table point to the bootloader code or the chibios code? the table is in flash so it is not possible to "take" a vector at runtime.

Giovanni

[rew]

OFFTOPIC:
Things start to work after I got the vector table correct.

boot0 jumpered for "system memory".
Hardware copies boot0 and boot1 into the SYSCFG->CFGR1 , this maps system memory including its vector table into "boot space" at 0x0000.

Just like ChibiOS, the bootloader is coded to "think" it is at its primary address of 0x1fffxxxx , not at 0x0000000. So the boot vector immediately points it to the original copy, not the "alias" at 0x000000.

I then politely ask the bootloader to "jump to my program". This jumps through the vector at 0x08000004.

If I immediately modify SYSCFG->CFGR1 to map FLASH into "bootspace", all is well: interrupts that Chibios uses now point to the flash.

On the Cortex M0, the vector table seems(*) fixed at 0x0000000. Only "what's mapped there" can be changed with the bottom two bits of CFGR1, which are loaded from the BOOT0 and BOOT1 pins by the hardware.

(*) The manual says something like "at reset it is fixed at 0x0000". Fine, but what about AFTER reset? (on Cortex M4, you could also say "at reset it is fixed at 0x0000"... "but after reset you can change the location of the vector table by modifying the VTOR register.")

ONTOPIC:
When my app boots after the bootloader has run, serial communcations seem "off by about 10%". This results in about 50% of the transmitted bytes being garbled. (Standard practise says: a deviation of the real baud rate by 3% is acceptable. That means things are guaranteed to work 100%. In practise you need about a 10% deviation before you start getting errors. Assuming the other side has 0% deviation.)

As the serial communications seem "off", My first thought was: Those have been used by the bootloader, so they might not be "virgin". But resetting them through RCC doesn't help. So there must be something else that the bootloader has touched.

With the serial ports not working, my debugging is a bit more difficult. Normally I could say "dump e000ed00 to dump the Most of the SCB (that address is of an 'M4 which I just happen to have on my screen right now).

I'll see if I can doublecheck the clock speed of the chip.

[rew]

Update: The CPU is running about 5.5 to 5.6 percent slower when started from the bootloader than when started from a real "reset".

Update: To communicate with the ESP8266 wifi module, just adding "121500" in the list-of-baud-rates-to-try is not enough: 115200 works "well enough" for the "does it work?" test (send AT, expect OK), but not enough for acutal more complicated communications. Putting 121500 first on the list-to-try helps. I now have my system working chain-loaded from the bootloader.

Update: RCC->CR = 0x03005a83;
fixes the problem. The magic number was given by the debugger:

Code: Select all

(gdb) printf "%08x\n", *(int*)0x40021000
03005a83

Of course I don't expect the calibration to be the same for other chips. I'm going to read up on where the numbers come from...

Update: The HSICAL part of RCC->CR is documented as readonly. After the bootloader runs, I get a different value. Ah! behind the scenes the stored calibration value and the trim value are added, and that is what you read back in HSICAL. So, I probably need to set HSITRIM back to the "reset value".....

[rew]

UPDATE: it is documented... sort of: AN2606, page 58:

When the user application configures a value of HSI TRIM bits (in RCC_CR register) and then jumps to the bootloader, the HSITRIM value is reset to its default value (0) at bootloader startup

The problem is: HSITRIM default value is NOT 0. It is 16. This is the documentation for the '051, while I'm working with the 072, which has no such "known problem".

With "autobauding" on the serial ports, and "crystalless" USB operation, this seems to be a problem that most people don't run into....
I have an external crystal sitting on my board. Just haven't gotten around to enabling that.

[Giovanni]

It should be responsibility of the bootloader to restore registers to the same values they had on entry (regardless what it is stated on the RM, the two things can differ, some registers contain calibration values).

Giovanni

[rew]

The problem is that someone, AT ST!!!, misread the reference manual and restored the register to the WRONG reset value.