Dear Friends,
I'm doing some test on vector table in the libmaple and on bootloader on branch retv6.
I found some inconsistency on vector table , i yet told with iperry about it and i see that i patch it on the github , i forget to told iperry that also i delete the ifdef in vector table to see it work , because if i don't delete it the effect was same that when that code there aren't . So i saw in bootloader retv6 branch is used the attolic script for medium density and not for high density. I think that also that portion of code could be update ... i try to update it and i saw that i upload right the code and see it start but my impression is that there're some problem on vector table or on ram definition because after a while freeze.
In my sample program i initialize a serial port 1 , then try to write on serial port .. . i try to write : "Welcome Serial1" instead on the port i saw "Welcome Serial" after it write the firmware freeze. The other portion of code simple wait available byte on the serial port and then write on serial1 the byte recived.
So my idea is that when start recive the data on serial the interrupt is active but is not served in right way.
So one questions i see that the vector table if i compile as flash is remapped in another location not in the original position where normal is mapped if i compile in JTAG mode. SO I think that the bootloader that is the first program that start on the board manage it the correct hardware interrupt and then with a jump istrcution send the call to remapped interrupt .. My idea is correct ?
I think that there're some problem in this part of code ... infact a native code could have the vector table in bootloader for high density don't medium density because if the startup code try to manage uart4 for example or other interrupt available on HD micro.
I hope that my explanation is clear .. :(
best
Roberto
P.S.
congratulation for your hard work i hope that my support is usefull :)
Suggestions on vectort table on native branch of code and on bootloader.
(3 posts) (2 voices)-
Posted 4 years ago #
-
mbolivar
LeafLabsHi Roberto,
I'm assuming you mean the "maple-ret6" branch in the maple-bootloader repository. Just to be clear, note that this is NOT a "Maple Rev 6" version. There is no Maple Rev 6 (yet). This is a version for the upcoming Maple RET 6 Edition, which features an STM32F103RET6 (instead of an "..RBT6", hence the name).
If I'm understanding you correctly, you're saying that the maple-ret6 bootloader branch is using a medium-density startup script, instead of a high-density one? If so, then yes, you've found a bug -- we forgot to update the stm32_lib directory to include high density linker scripts. I'll get to it soon, but patches are welcome :).
Thanks for all your recent bug reports for high-density chips. Sorry that the maple-bootloader repository is a mess right now, with all of those different branches instead of appropriate #ifdefs. Our goal is to make the bootloader just another program that links against libmaple; when that happens, we'll be able to use the STM32_[MEDIUM,HIGH]_DENSITY #defines currently in use in the libmaple refactor branch to get everything working portably from a single code base.
Posted 4 years ago #
Reply
You must log in to post.