Note: The MSP430_HAS_EXTERNAL_CRYSTAL would indicate that the XT2 clock should be used instead of the DCO. However, the msp430_init_dco() in the TelosB's board.c configures and calibrates the DCO as clock source regardless of that macro. It seems to be a copy-paste error.

Also note: It should now be possible to run the DCO at 4 MHz instead of ~2.5 MHz, as the DCO calibration is a bit more robust.

How did this ever work? The clock was initialized to run at ~2.5 MHz from DCO due to

#define MSP430_INITIAL_CPU_SPEED    2457600uL
#define F_CPU                       MSP430_INITIAL_CPU_SPEED
#define F_RC_OSCILLATOR             32768
#define MSP430_HAS_DCOR             1
#define MSP430_HAS_EXTERNAL_CRYSTAL 0

But CLOCK_CORECLOCK was ~7.4 MHz ans so was CLOCK_CMCLK, which was used to configure the UART symbol rate to 9600 Baud. The actual symbol rate like was then 3200 Baud due to this mismatch :-/

Update: I double checked: The datasheet says that the DCO tops out at 5.4 MHz maximum, even if the the silicon lottery gave one an extra fast DCO (the production variance is said to be significant) and the supply voltage is extra high. In fact, 4.9 MHz is the typical max frequency at 3 V. The sanity test prevents more than 4 MHz to account for poor luck in the silicon lottery + a low supply voltage.

The good thing is that the compile time configuration sanity tests do indeed work and caught the issue.

any info on what this is?

It is the start address of the info mem segment of the flash:

The info mem is actually just normally flash, but the blocks are smaller. This makes it more suitable as EEPROM replacement, as a read-modify-erase-write cycle would be faster due to the smaller block size.

It may be useful for an application to have that address to easily read application data from flash stored there. Likely, it would be better to use the linker (the vendor provided linker files define the INFOMEM memory) to access that, though.

If that's a hardware property (e.g. can't be configured by the board) it should be defined by the CPU - and be documented.

I reckon we also don't place firmware there, but instead have a special linker section for this memory?

That would be how IMO we should do it. As of now, it is up to the application developer to use it.

This is certainly on the list of todos for cleaning up the MSP430 platform; as well as cleaning up all of the periph drivers. (Likely the periph drivers are more pressing.)

My original plan was to get in support for the Olimex board without doing any cleanup, so that I can work and test the cleanup with real hardware without having to juggle to much out of tree code. However, adding another copy of the void msp430_init_dco(void) function implementing the exact same thing for every board is something that just felt too wrong.

Still, I would like to keep the INFOMEM as a define and on board level for now. Moving that to CPU level would however be swift and easy follow-up PR that I could do prior to cleaning up the peripherals.