Dear all. First of all, I found an anomaly at the initialization of either GPIO or TIM. The problem is that it is enough to have one of the peripherals of the group e.g. TIM2, in order for the compiler an linker to generate entries for all of the timers TIMx. The same behaviour applies to GPIOx. https://github.com/supramaterial/Runtime/blob/master/stm32/variants/ellduino/ellduino.cpp#L40 Apparently the problem is at the definition of the macros that initialize: https://github.com/supramaterial/Runtime/blob/master/stm32/cores/arduelli/arduelli_timer.h#L52 For some reason as far as it requires one reference, generates the references for all the others. Although that is not that relevant for TIM or GPIO, has an effect on USART (serial). As far as I remember, the objective was to only initialize the USART that is required (not both of them as right now). Talking about USART, I've played a little with the new update. The first problem is that as there is no explicit reference to the initialization records, they are not compiled and the table not updated with those values. First I tried to make an explicit reference through the Serial struct: https://github.com/supramaterial/Runtime/commit/90f510c298f08dc3f2c5c8846633552c244ab115#diff-203aebca74cabb67173ad86c43fec391R100 Unfortunately it didn't work. I am not sure if it should work anyway. By a quick check at the assembly it looks that the function calls are optimized to simply access the registers. Then I simply used the old trick of referring the initializer tables from ellduino.cpp: https://github.com/supramaterial/Runtime/commit/90f510c298f08dc3f2c5c8846633552c244ab115#diff-124031342aa453ca23ad5d871e33fa09R55 Although I managed to get the initialization tables in the correct order by reversing them, still I got no output on the serial, for both, Serial and Serial1. Hope this information is useful. I will continue tomorrow to try to get some output by the ellduino.cpp trick for the tables. Pekka: What do you suggest now? With Warm Regards, Ivan Raul