Mirrors_Framework/nuttx
1
0
Fork 0
mirror of https://github.com/apache/nuttx.git synced 2026-05-18 00:34:10 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

arch/arm/src/s32k1xx/hardware/s32k1xx_flexcan.h: Add an incomplete FlexCAN register definition header file. Still missing some bitfield definition. Also updates some README files.

Browse Source
This commit is contained in:
Gregory Nutt
2019-08-23 07:35:28 -06:00
parent 6ecee7e403
commit b3d609959c
3 changed files with 600 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
arch/arm/src/s32k1xx/hardware/s32k1xx_flexcan.h
+576
View File
File diff suppressed because it is too large Load Diff
boards/arm/s32k1xx/s32k118evb/README.txt
+8 -14
View File
@@ -15,25 +15,19 @@ Contents
Status
======
2019-08-14: Configuration created but entirely untested. Support for the
S32K1XX family is incomplete. This configuration is intended, initially,
to support development of the architecture support. This is VERY much
a work in progress and you should not use this configuration unless you
are interested in assisting with the bring-up.
2019-08-14: Configuration created but entirely untested.
2019-08-17: The port is code complete. It compiles with no errors or
warnings but is untested. Still waiting for hardware.
2019-08-20: I have the board and started the debug. However, the
very first image that I wrote to FLASH seems to have "bricked" the
board. I believe that the S32K118 resets into a bad state and
cannot interface with the OpenSDA, effectively cutting it off from
the world. I will continuing the bring-up using the S32K146EVB
where I can run from SRAM for the initial bring-up.
2019-08-20: The very first image that I wrote to FLASH seems to
have "bricked" the board. The board is sensitive to (1) resetting
into a bad state and (2) incorrect flash configurations. It is
difficult to impossiblel to recover from these start-up errors.
These bring-up issues were addressed with S32K146EVB. It is not probably
safe to try the S32K118EVB again (if I can figure out how to break into
my bricked system).
2019-80-22: My S32K118EVB is still borked, but after some additional
changes, Fabio Balzano has verified that the NSH is functional on
that board.
Serial Console
==============
boards/arm/s32k1xx/s32k146evb/README.txt
+16 -10
View File
@@ -15,19 +15,25 @@ Contents
Status
======
2019-08-18: Configuration created but entirely untested. This
configuration is intended, initially, to verify s32k14x architecture
support. The configuration builds and links without error but has
not yet been tested. This is VERY much a work in progress and you
should not use this configuration unless you are interested in
assisting with the bring-up.
2019-08-18: Configuration created but entirely untested.
2019-08-20: Initial testing, I am running out of SRAM to avoid the
2019-08-20: For initial testing, I ran out of SRAM to avoid the
brickage problems I had with the S32K118EVB (i.e., with
CONFIG_BOOT_RUNFROMISRAM=y).
CONFIG_BOOT_RUNFROMISRAM=y). In this mode, the NSH configuration
appears worked correctly.
The NSH configuration now appears work correctly. Only verified when
running SRAM at present.
2019-18-21: Writing a relocated version of that same functional binary
into FLASH, however, did not work and, in fact, bricked my S32K146EVB.
That is because the first version of the FLASH image that I used
clobbered the FLASH Configuration bytes at address 0x0400 (I
didn't even know about these!). I have since modified the linker script
to skip this are in FLASH. There is some fragmentary discussion
for recovery from this condition at: https://community.nxp.com/thread/505593 .
But none of those options are working for me.
Give the success running of of SRAM and the success of the same fixes
on the S32K118, I believe that the NSH configuration should now run out
of FLASH. Unfortunately, I cannot demonstrate that.
Serial Console
==============