* sn32: 2xx: centralize peripheral clock functions
* sn32: export HCLK for all boards
* sn32: support tickless mode for systick
* sn32: CT: cleanup inclusions
* Revert "sn32: export HCLK for all boards"
This reverts commit 1cae8892e3ce908ef89774a7e83bb921ecd810fc.
* sn32: export HCLK in hal level
* ST: inherit the SN32_HCLK
* 2xx lld: include ct header
* ST: fix systime type
* ST: interrupt should be disabled on init
* st: cleanup
* debug it
* Revert "debug it"
This reverts commit 1dd78e81019aa1233f3402ed251428085470ab79.
* sn32f2xx: make sure clocks match and proper timer init
* add more checks
* always read 32 bits from the counter
* read the first 16 bits directly
* systime_t is 16bits, but MR0 lives in a 32bit register
* testing: use ILRC
* testing: hack
* Revert "testing: hack"
This reverts commit 3821173dd9a6180e3f91a3e81e73e9f92385e273.
* Revert "testing: use ILRC"
we can't do this because hardware limits
This reverts commit 19d3ffefbce8cdd5cd34859cd8befccda6353e58.
* fix assert
* test: hardcode it
* Revert "test: hardcode it"
This reverts commit a75777c44d12844eb0be44c650a1de1602cadaed.
* add preliminary support for the whole SN32F2XX series
* unify CMSIS support, no more ugly hacks
* rename the unified hal to SN32F2XX
* common header amongst the hal, points to device
* add board files for the series
* 240 gets to keep it's own hal for now
* Fixed bug in sys clock init, also reported by glory
* Removed modification of SN_FLASH->LPCTRL from SystemCoreClockUpdate(). SystemCoreClockUpdate() should only update the SystemCoreClock variable.
This is taken from the latest pack file called:
"SONiX.SN32F2_DFP.1.2.11.pack"
This pack file is found in an archive named:
"SN32F260_Startkit_Package_V1.6R.zip"
download from here:
http://www.sonix.com.tw/article-en-998-24753 or
http://www.sonix.com.tw/files/1/9BB279642CFC9359E050007F01007A12
(extract that zip file and look in the "Pack" folder)
if you rename "SONiX.SN32F2_DFP.1.2.11.pack" to "SONiX.SN32F2_DFP.1.2.11.zip" you can extract it with a normal zip program
You find the file "SN32F260.h" in the folder "Device/Include"
The startup code that initializes the mcu is moved to be the first entry
in the vectors section, so it will always be the first to run after a reset.
Because of a typo the vector table would have been there, but was relocated
into the text section. So this setup compiled by sheer luck into a working executable
that had the _start function at the flash base (0x8000000) up to this point.
An oversight when arrangeing the code according to the nucleisys docs,
t0 was overriden with the value of msubm and never actually restored. To
fix the issue we restore the csrs after the general purpose registers.
The offical docs want it the other way around but this should be fine as
well, as the interrupts are still globaly disabled at this point.
The first attempt to solve illegal instruction expections was made in commit
b875108cd0
It seemed as this "fixed" the issue, but merely added delays in the code
which prevented the error to appear in lucky circumstances. Interesting that this code worked in the first place.
Root cause for the expections where write attempts to mstatus in
user privilege mode which raised the illegal instruction exception which
is in spec with the risc-v privileged isa and documented in the
bumbleebee core architecture manual by nucleisys. The solution is
to never enter user mode by forceing mcause.mpp to 0x3
before calling mret when exiting the interrupt handler
for context switching.
plewka
Fabien Poussin
Joy
fauxpark
dexter93
IsaacDynamo
janjan
HorrorTroll
Stephen Peery
zykrahgaming
Stefan Kerkmann
Hanya