OrgApache/incubator-nuttx
OrgApache
/
incubator-nuttx
mirror of https://github.com/apache/incubator-nuttx.git
1
0
Fork 0
Code Issues Releases Wiki Activity
incubator-nuttx/boards/arm/samd5e5/metro-m4/README.txt

324 lines
12 KiB
Plaintext
Raw Blame History

README
======
This directory contains the port of NuttX to the Adafruit Metro M4. The
Metro M4 uses a Arduino form factor and and pinout. It's powered with an
ATSAMD51J19:
o Cortex M4 core running at 120 MHz
o Hardware DSP and floating point support
o 512 KB flash, 192 KB RAM
o 32-bit, 3.3V logic and power
o Dual 1 MSPS DAC (A0 and A1)
o Dual 1 MSPS ADC (8 analog pins)
o 6 x hardware SERCOM (I2C, SPI or UART)
o 16 x PWM outputs
o Stereo I2S input/output with MCK pin
o 10-bit Parallel capture controller (for camera/video in)
o Built in crypto engines with AES (256 bit), true RNG, Pubkey controller
o 64 QFN
Contents
========
o STATUS
o Unlocking FLASH
o Serial Console
o LEDs
o Run from SRAM
o Configurations
STATUS
======
2018-07-26: The basic port was merged into master. It is still
incomplete and untested.
2018-07-29: Code complete. Clock configuration complete. Unverified
SERCOM USART, SPI, I2C, Port configuration, and DMA support have been
added. I still have no hardware in hand to test.
2018-07-20: Brought in the USB driver from the SAML21. It is the same
USB IP with only small differences. There a a few, small open issues
still to be resolved.
2018-08-01: Hardware in hand. Initial attempts to program the board
using a Segger J-Link connected via SWD were unsuccessful because the
Metro M4 comes with an application in FLASH and the FLASH locked. See
"Unlocking FLASH with J-Link Commander" below. After unlocking the
FLASH, I was able to successfully write the NuttX image.
Unfortunately, the board seems to have become unusable after the first
NuttX image was written to FLASH. I am unable to connect the JTAG
debugger. The primary JTAG problem seems to be that it is now unable
to halt the CPU.
Future me: This boot-up failure was do to bad clock initialization
logic that caused infinite loops during clock configuration. Unlocking
and erasing the FLASH is innocuous, but the JTAG will apparently not
work if the clocks are not in a good state.
I would say that as a general practice, any changes to the clock
configuration should be testing in SRAM first before risking the
write to FLASH.
2018-08-03: Added a configuration option to run out of SRAM vs FLASH.
This is a safer way to do the initial board bring-up since it does
not modify the FLASH image nor does it require unlocking the FLASH
pages.
2018-08-31: I finally have a new Metro M4 and have successfully
debugged from SRAM (with FLASH unlocked and erased). Several
errors in clock configuration logic have been corrected and it now
gets through clock configuration okay. It now hangs in the low-level
USART initialization.
It hangs trying to enabled the SERCOM slow clock channel. The clock
sequence is:
1. 32.678KHz crystal -> XOSC32K
This is configured and says that XOSC32K is ready.
2. XOSCK32 -> GCLK3.
This is configured and it says that is is ready (GENEN=1).
3. GCLK3 ->SERCOM slow clock channel.
This hangs when I try to enable the peripheral clock.
2018-09-01: I found a workaround by substituting OSCULP32K for XOSC32
as the source to GCLK3. With that workaround, the port gets past all
clock and USART configuration. A new configuration option was added,
CONFIG_METRO_M4_32KHZXTAL. By default this workaround is in place.
But you can enable CONFIG_METRO_M4_32KHZXTAL if you want to further
study the XOSC32K problem.
With that workaround (and a bunch of other fixes), the basic NSH
configuration appears fully function, indicating the the board bring-
up is complete.
There are additional drivers ported from SAML21 which has, in most cases,
identical peripherals. None of these drivers have been verified on the
SAMD51, However. These include: DMAC, I2C, SPI, and USB.
WARNING: If you decide to invest the time to discover whey the XOSC32K
clock source is not working, be certain to use the SRAM configuration.
That configuration in FLASH is most likely lock up your board irrecoverably
is there are any start-up errors!
Unlocking FLASH
===============
Options
-------
The Adafruit Metro M4 comes with a very nice bootloader resident in FLASH.
so we have two options:
1. Learn to play well with others. Make NuttX coexist and work in the
memory partition available to it. Or,
2. Be greedy, unlock the FLASH and overwrite the bootloader.
I chose to do the last one. I used a Segger J-Link and here are the steps
that I took. You can probably do these things in Atmel Studio (?) but for
other debug environments, you would have to come up with the solution.
Unlocking FLASH with J-Link Commander
-------------------------------------
1. Start J-Link Commander:
SEGGER J-Link Commander V6.32i (Compiled Jul 24 2018 15:20:49)
DLL version V6.32i, compiled Jul 24 2018 15:19:55
Connecting to J-Link via USB...O.K.
Firmware: J-Link V9 compiled Apr 20 2018 16:47:26
Hardware version: V9.30
S/N: 269303123
License(s): FlashBP, GDB
OEM: SEGGER-EDU
VTref=3.296V
Type "connect" to establish a target connection, '?' for help
J-Link>con
Please specify device / core. <Default>: ATSAMD51P19
Type '?' for selection dialog
Device>ATSAMD51P19
Please specify target interface:
J) JTAG (Default)
S) SWD
TIF>S
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "ATSAMD51P19" selected.
Connecting to target via SWD
Found SW-DP with ID 0x2BA01477
Scanning AP map to find all available APs
...etc. ...
2. Look at The NVM "user page" memory at address 0x00804000:
J-Link>mem8 804000, 10
00804000 = 39 92 9A F6 80 FF EC AE FF FF FF FF FF FF FF FF
The field NVM BOOT (also called BOOTPROT) is the field that locks the
lower part of FLASH to support the boot loader. This is bits 26-29
of the NVM user page:
J-Link>mem32 804000, 1
00804000 = F69A9239
In binary 11|11 01|10 1001 1010 1001 0010 0011 1001, so NVM Boot 1101.
To unlock the FLASH memory reserved for the bootloader, we need to
change this field to 111 so that:
11|11 11|10 10|01 1010 1001 0010 0011 1001 = F7da9239, or
00804000 = 39 92 9A FE 80 FF EC AE FF FF FF FF FF FF FF FF
is read.
3. Modify the NVM "user page"
I did this using the instructions for the SAMD21 found at
https://roamingthings.de/use-j-link-to-change-the-boot-loader-protection-of-a-sam-d21/
We will need to create a small Motorola S-REC file to write new values
into NVM. See https://en.m.wikipedia.org/wiki/SREC_(file_format) for a
description of the Motorola SREC format.
I wrote a small program at boards/arm/samd5e5/metro-m4-scripts/nvm.c that will
generate this Motorola SREC file with the correct checksum. The file at
boards/arm/samd5e5/metro-m4-scripts/nvm.c is the output of that program.
J-Link>mem8 804000,10
00804000 = 39 92 9A F6 80 FF EC AE FF FF FF FF FF FF FF FF
J-Link>loadfile D:\Spuda\Documents\projects\nuttx\master\nuttx\boards\metro-m4\scripts\nvm.srec
Downloading file [D:\Spuda\Documents\projects\nuttx\master\nuttx\boards\metro-m4\scripts\nvm.srec]...
J-Link: Flash download: Bank 1 @ 0x00804000: 1 range affected (16 bytes)
J-Link: Flash download: Total time needed: 0.089s (Prepare: 0.035s, Compare: 0.011s, Erase: 0.000s, Program: 0.019s, Verify: 0.011s, Restore: 0.011s)
O.K.
J-Link>mem8 804000,10
00804000 = 39 92 9A FE 80 FF EC AE FF FF FF FF FF FF FF FF
You will, of course, have to change the path as appropriate for your system.
4. Erase FLASH (optional)
J-Link>erase
Erasing device (ATSAMD51P19)...
J-Link: Flash download: Total time needed: 2.596s (Prepare: 0.031s, Compare: 0.000s, Erase: 2.553s, Program: 0.000s, Verify: 0.000s, Restore: 0.012s)
J-Link: Flash download: Total time needed: 0.066s (Prepare: 0.038s, Compare: 0.000s, Erase: 0.016s, Program: 0.000s, Verify: 0.000s, Restore: 0.010s)
Erasing done.
J-Link>
Serial Console
==============
An Arduino compatible serial Shield is assumed (or equivalently, and
external RS-232 or serial-to-USB adapter connected on Arduino pins D0 and
D1):
------ ----------------- -----------
SHIELD SAMD5E5 FUNCTION
------ ----------------- -----------
D0 PA23 SERCOM3 PAD2 RXD
D1 PA22 SERCOM3 PAD0 TXD
LEDs
====
The Adafruit Metro M4 has four LEDs, but only two are controllable by software:
1. The red LED on the Arduino D13 pin, and
2. A NeoPixel RGB LED.
Currently, only the red LED is supported.
------ ----------------- -----------
SHIELD SAMD5E5 FUNCTION
------ ----------------- -----------
D13 PA16 GPIO output
Run from SRAM
=============
I bricked my first Metro M4 board because there were problems in the
bring-up logic. These problems left the chip in a bad state that was
repeated on each reset because the code was written into FLASH and I was
unable to ever connect to it again via SWD.
To make the bring-up less risky, I added a configuration option to build
the code to execution entirely out of SRAM. By default, the setting
CONFIG_METRO_M4_RUNFROMFLASH=y is used and the code is built to run out of
FLASH. If CONFIG_METRO_M4_RUNFROMSRAM=y is selected instead, then the
code is built to run out of SRAM.
To use the code in this configuration, the program must be started a
little differently:
gdb> mon reset
gdb> mon halt
gdb> load nuttx << Load NuttX into SRAM
gdb> file nuttx << Assuming debug symbols are enabled
gdb> mon memu32 0x20000000 << Get the address of initial stack
gdb> mon reg sp 0x200161c4 << Set the initial stack pointer using this address
gdb> mon memu32 0x20000004 << Get the address of __start entry point
gdb> mon reg pc 0x20000264 << Set the PC using this address (without bit 0 set)
gdb> si << Step in just to make sure everything is okay
gdb> [ set breakpoints ]
gdb> c << Then continue until you hit a breakpoint
Where 0x200161c4 and 0x20000264 are the values of the initial stack and
the __start entry point that I read from SRAM
Configurations
==============
Each Adafruit Metro M4 configuration is maintained in a sub-directory and
can be selected as follow:
tools/configure.sh [OPTIONS] metro-m4:<subdir>
Do 'tools/configure.sh -h' for the list of options. If you are building
under Windows with Cygwin, you would need the -c option, for example.
Before building, make sure that the PATH environmental variable includes the
correct path to the directory than holds your toolchain binaries.
And then build NuttX by simply typing the following. At the conclusion of
the make, the nuttx binary will reside in an ELF file called, simply, nuttx.
make
The <subdir> that is provided above as an argument to the tools/configure.sh
must be is one of configurations listed in the following paragraph.
NOTES:
1. These configurations use the mconf-based configuration tool. To
change any of these configurations using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. Unless stated otherwise, all configurations generate console
output of on SERCOM3 which is available on a Arduino Serial
Shield (see the section "Serial Console" above).
3. Unless otherwise stated, the configurations are setup build under
Linux with a generic ARM EABI toolchain:
Configuration sub-directories
-----------------------------
nsh:
This configuration directory will built the NuttShell. See NOTES ;for
common configuration above and the following:
NOTES:
1. The CMCC (Cortex M Cache Controller) is enabled.
Reference in New Issue View Git Blame Copy Permalink