Page 1 of 2
Support for STM32F730 Value line MCUs
Posted: Fri Dec 20, 2019 9:29 pm
by tecnologic
Hi All,
i'm currently porting chibios to STM32F730x8 series. I needed to update the stm header files and created a linker script but when i boot the code i'm immediately struck at _port_switch. which is kind of strange because the call stack says its coming from the first line in the Reset_Handler: b _crt0_entry. I susspect there is some general error either in the code or the linkage.
i attached my changes as a patch but for reference the original code is here:
UNIMOC Code
Re: Support for STM32F730 Value line MCUs
Posted: Fri Dec 20, 2019 10:01 pm
by tecnologic
Its always this vector: VectorF8() at vectors.S:1,021 0x200332
strange thing. if i run the f722 demo i dont have the issue. Ideas?
Thanks.
Re: Support for STM32F730 Value line MCUs
Posted: Sat Dec 21, 2019 6:34 am
by Giovanni
Is the device really flashed?
Giovanni
Re: Support for STM32F730 Value line MCUs
Posted: Sat Dec 21, 2019 4:18 pm
by tecnologic
Hi Giovanni,
yes i'm quite sure it is flashed. When i build the F722ZI Demo i just copy the elf file to the spot of my projects elf file and start the debugger with the same settings. I had a look at stm32_regitsty.h and everything seems to work as expected. I get the j-link download progressbars every time i switch elf files. And verify flash is on as well.
I know i missed some thing in the port but i have no idea whats the problem. The linker script is fine because i changed the demo to use that. I even change the board.h of the demo to define STM32F730xx instead of STM32F722xx. But i cant break the demo. So there must be something wrong with my code and not the port?
Re: Support for STM32F730 Value line MCUs
Posted: Sat Dec 21, 2019 4:38 pm
by tecnologic
Update:
It was my code. The port is WORKING!. If u need any thing more than the patch please ask.
Alex
Re: Support for STM32F730 Value line MCUs
Posted: Sat Dec 21, 2019 5:59 pm
by tecnologic
I found the issue with my code. If i use the cpp wrappers and define a thread that overrides the pure virtual main function of the BaseStaticThread class. I have the issue. This look to me more like a compiler problem or does any one have a idea whats happening?
The code is as simple as that:
Code: Select all
#include "ch.hpp"
#include "hal.h"
using namespace chibios_rt;
/* Reference to the server thread.*/
static ThreadReference sref;
/*
* LED blink sequences.
* NOTE: Sequences must always be terminated by a GOTO instruction.
* NOTE: The sequencer language could be easily improved but this is outside
* the scope of this demo.
*/
#define SLEEP 0
#define GOTO 1
#define STOP 2
#define BITCLEAR 3
#define BITSET 4
#define MESSAGE 5
typedef struct {
uint8_t action;
union {
msg_t msg;
uint32_t value;
ioline_t line;
};
} seqop_t;
// Flashing sequence for LED3.
static const seqop_t LED3_sequence[] =
{
{BITSET, LINE_LED_RUN},
{SLEEP, 800},
{BITCLEAR, LINE_LED_RUN},
{SLEEP, 200},
{GOTO, 0}
};
// Flashing sequence for LED4.
static const seqop_t LED4_sequence[] =
{
{BITSET, LINE_LED_MODE},
{SLEEP, 600},
{BITCLEAR, LINE_LED_MODE},
{SLEEP, 400},
{GOTO, 0}
};
// Flashing sequence for LED5.
static const seqop_t LED5_sequence[] =
{
{BITSET, LINE_LED_ERROR},
{SLEEP, 400},
{BITCLEAR, LINE_LED_ERROR},
{SLEEP, 600},
{GOTO, 0}
};
// Flashing sequence for LED6.
static const seqop_t LED6_sequence[] =
{
{BITSET, LINE_LED_PWM},
{SLEEP, 200},
{BITCLEAR, LINE_LED_PWM},
{SLEEP, 800},
{GOTO, 0}
};
/*
* Sequencer thread class. It can drive LEDs or other output pins.
* Any sequencer is just an instance of this class, all the details are
* totally encapsulated and hidden to the application level.
*/
class SequencerThread : public BaseStaticThread<128>
{
private:
const seqop_t *base, *curr; // Thread local variables.
protected:
void main(void) override {
setName("sequencer");
while (true) {
switch(curr->action) {
case SLEEP:
sleep(TIME_MS2I(curr->value));
break;
case GOTO:
curr = &base[curr->value];
continue;
case STOP:
return;
case BITCLEAR:
palClearLine(curr->line);
break;
case BITSET:
palSetLine(curr->line);
break;
}
curr++;
}
}
public:
SequencerThread(const seqop_t *sequence) : BaseStaticThread<128>() {
base = curr = sequence;
}
};
/* Static threads instances.*/
static SequencerThread blinker1(LED3_sequence);
static SequencerThread blinker2(LED4_sequence);
static SequencerThread blinker3(LED5_sequence);
static SequencerThread blinker4(LED6_sequence);
/*
* Application entry point.
*/
int main(void) {
/*
* System initializations.
* - HAL initialization, this also initializes the configured device drivers
* and performs the board-specific initializations.
* - Kernel initialization, the main() function becomes a thread and the
* RTOS is active.
*/
halInit();
System::init();
/*
* Normal main() thread activity, in this demo it does nothing except
* sleeping in a loop and check the button state.
*/
while (true) {
BaseThread::sleep(TIME_MS2I(500));
}
}
Thanks
Re: Support for STM32F730 Value line MCUs
Posted: Sat Dec 21, 2019 6:06 pm
by Giovanni
A 27MB patch?
Giovanni
Re: Support for STM32F730 Value line MCUs
Posted: Sat Dec 21, 2019 10:31 pm
by tecnologic
Hi Giovanni,
my bad, i updated all the STM32 headers these make the patch so huge. I seperated the changes, so please find attached the real changes to the os code without the ST headers in os/common/ext/st.
Alex
Re: Support for STM32F730 Value line MCUs
Posted: Mon Dec 23, 2019 11:04 am
by alex31
tecnologic wrote:I found the issue with my code. If i use the cpp wrappers and define a thread that overrides the pure virtual main function of the BaseStaticThread class. I have the issue. This look to me more like a compiler problem or does any one have a idea whats happening?
Thanks
Hello,
perhaps a static C++ object initialisation problem ?
do you link with g++ ?
Alexandre
Re: Support for STM32F730 Value line MCUs Topic is solved
Posted: Mon Dec 23, 2019 12:23 pm
by steved
There was a bug in the scatter files which caused problems linking static classes (IIRC); might be a similar problem here. It's fixed in trunk, but not in the standard 19.1.3 distribution.
Check os\common\startup\ARMCMx\compilers\GCC\ld\rules_Code.ld - line 38 or thereabouts should say: