a2e62f557d
sched/init/nx_bringup.c: Fix a naming collision.
sched/init: Rename os_start() to nx_start()
sched/init: Rename os_smp* to nx_smp*
sched/init: Rename os_bringup to nx_bringup
sched/init: rename all internal static functions to begin with nx_ vs os_
205 lines
7.0 KiB
Plaintext
205 lines
7.0 KiB
Plaintext
README
|
||
======
|
||
|
||
This directory holds NuttX board support for the Maxim Integrated
|
||
MAX32660-EVSYS board. That board features:
|
||
|
||
o MAX32660 Microcontroller
|
||
- Arm Cortex-M4F, 96MHz
|
||
- 256KB Flash Memory
|
||
- 96KB SRAM
|
||
- 16KB Instruction Cache
|
||
- Two SPIs
|
||
- Two I2Cs
|
||
- Two UARTs
|
||
- 14 GPIOs
|
||
o DIP Breakout Board
|
||
- 100mil Pitch Dual Inline Pin Headers
|
||
- Breadboard Compatible
|
||
o Integrated Peripherals
|
||
- Red Indicator LED
|
||
- User Pushbutton
|
||
o MAX32625PICO-Based Debug Adapter
|
||
- CMSIS-DAP SWD Debugger
|
||
- Virtual UART Console
|
||
|
||
Contents
|
||
========
|
||
|
||
o Status
|
||
o Serial Console
|
||
o LEDs and Buttons
|
||
o OpenOCD
|
||
|
||
Status
|
||
======
|
||
|
||
2018-11-21: The port is code complete but completely untested. I am
|
||
still waiting to receive hardware to perform the bringup. This initial
|
||
port will support an NSH console: Clock configuration, timer, GPIO
|
||
pin configuration, ICC, and UART. Additional untested drivers are
|
||
complete and ready for testing: DMA, GPIO interrupts, RTC, WDT. The
|
||
following drivers are not implemented: I2C, SPI, I2S.
|
||
2018-11-27: I received the MAX32660-EVSYS today and made a little debug
|
||
progress. Added a run-from-SRAM configuration to keep from locking
|
||
up the board on bad configurations. The rest of the bring-up will
|
||
use this SRAM configuration.
|
||
The NSH prompt comes up, but there is some interrupt-related problem
|
||
that makes the console unusable.
|
||
2018-11-28: Found that the WFI instruction in the IDLE loop was causing
|
||
instability. System ran OK until it was in IDLE then it became
|
||
unstable. Commenting out the WIF restores stability. The port now
|
||
runs safely from FLASH although still with missing UART interrupts.
|
||
Also fixed the on-board LED which now currently reflects the state.
|
||
2018-11-29: Resolved the UART interrupt issue. The NSH configuration
|
||
now appears fully functional. Removed EXPERIMENTAL from configuration.
|
||
Brought in the STM32 SPI driver as a starting point. It still does
|
||
not build correctly. Due to conflicts, only SPI0 will be available.
|
||
2018-11-30: Completed coding of the SPI driver. Added board support
|
||
for SPI and for and SPI-based micro-SD card. Initial testing with no
|
||
device attached shows that the first single byte SPI transfer hangs
|
||
with 1 byte in the Tx FIFO and nothing in the Rx FIFO. Data is not
|
||
moving.
|
||
|
||
I need to stop and work on some other things for a while. Here are the
|
||
things remaining to be done:
|
||
|
||
- Test the DMA, WDT and RTC drivers. These drivers are complete but
|
||
untested.
|
||
- Finish verification of the SPI0 master driver. It currently hangs as
|
||
described above.
|
||
- Add support for missing drivers.
|
||
|
||
Missing drivers include:
|
||
|
||
- SPI17Y: SPI0 master DMA support, SPI0 Slave
|
||
- SPIMSS: SPI1 master/slave, I2C
|
||
- I2C0/1 master/slave
|
||
- Timer/PWM
|
||
|
||
Serial Console
|
||
==============
|
||
|
||
UART1 Tx and Rx signals at port P0.10 and P0.11 are connected to the
|
||
programming and debug header JH2 pins 2 and 3 through 1kΩ resistors.
|
||
This provides a convenient way to communicate with a PC though the
|
||
virtual serial port available in Maxim’s CMSIS-DAP debug adapter. The
|
||
series resistors allow for these signals to be overdriven by other
|
||
circuits without modifying the board.
|
||
|
||
LEDs and Buttons
|
||
================
|
||
|
||
LEDs
|
||
----
|
||
|
||
A single red LED is available driven by GPIO P0.13.
|
||
|
||
This LED is not used by the board port unless CONFIG_ARCH_LEDS is
|
||
defined. In that case, the usage by the board port is defined in
|
||
include/board.h and src/sam_autoleds.c. The LED is used to encode
|
||
OS-related events as follows:
|
||
|
||
------------------- ----------------------- ------
|
||
SYMBOL Meaning LED
|
||
------------------- ----------------------- ------
|
||
LED_STARTED NuttX has been started OFF
|
||
LED_HEAPALLOCATE Heap has been allocated OFF
|
||
LED_IRQSENABLED Interrupts enabled OFF
|
||
LED_STACKCREATED Idle stack created ON
|
||
LED_INIRQ In an interrupt N/C
|
||
LED_SIGNAL In a signal handler N/C
|
||
LED_ASSERTION An assertion failed N/C
|
||
LED_PANIC The system has crashed FLASH
|
||
|
||
Thus if the LED is statically on, NuttX has successfully booted and is,
|
||
apparently, running normally. If the LED is flashing at approximately
|
||
2Hz, then a fatal error has been detected and the system has halted.
|
||
|
||
Buttons
|
||
-------
|
||
|
||
An single button is available on GPIO P0.12 for use by software.
|
||
|
||
OpenOCD
|
||
=======
|
||
|
||
Starting OpenOCD
|
||
----------------
|
||
|
||
An Eclipse based toolchain is available for download from Maxim Integrated.
|
||
If you (like me) are not an IDE user then the good news is the OpenOCD for
|
||
the MAX32660 is available within that toolchain.
|
||
|
||
As of this writing, the OpenOCD changes for the MAX32660 are not yet
|
||
incorporated into the mainline OpenOCD code so the Maxim Integrated version
|
||
within the Eclipse-based toolchain is the only show in town. Patches for
|
||
the MAX32660 have been submitted and this will most likely no longer be true
|
||
as you read this.
|
||
|
||
The Eclipse-based toolchain installs by default at C:\Maxim under Windows.
|
||
The following script tracks tracks down OpenOCD in that installation
|
||
(assuming Cygwin, hence the /cygdrive/c for the C: drive:
|
||
|
||
#!/bin/sh
|
||
|
||
set -x
|
||
|
||
OPENOCD=/cygdrive/c/Maxim/Toolchain/bin/openocd.exe
|
||
IFCFG="C:\Maxim\Toolchain\share\openocd\scripts\interface\max32660_hdk.cfg"
|
||
MCUCFG="C:\Maxim\Toolchain\share\openocd\scripts\target\max32660.cfg"
|
||
|
||
${OPENOCD} ${1} -f ${IFCFG} # -f ${MCUCFG}
|
||
|
||
Loading Code:
|
||
|
||
Code can be loaded into FLASH using the convenient ARM MBED drag'n'drop
|
||
interface. Or it can be loaded into FLASH (or SRAM) using GDB as follows:
|
||
|
||
$ arm-none-eabi-gdb
|
||
(gdb) target remote localhost:3333
|
||
(gdb) mon reset
|
||
(gdb) mon halt
|
||
(gdb) load nuttx
|
||
|
||
This does not work so reliably for me, however.
|
||
|
||
Debugging from FLASH:
|
||
|
||
$ arm-none-eabi-gdb
|
||
(gdb) target remote localhost:3333
|
||
(gdb) mon reset
|
||
(gdb) mon reg pc __start # Set PC to __start entry point
|
||
(gdb) file nuttx
|
||
(gdb) b nx_start
|
||
(gdb) c
|
||
|
||
Also not very reliable.
|
||
|
||
Debugging from SRAM:
|
||
|
||
Same except (1) that the __start entry point is 0x2000011c, not 0x11c, and
|
||
the code needs to be reloaded into SRAM each time:
|
||
|
||
(gdb) target remote localhost:3333
|
||
(gdb) mon reset
|
||
(gdb) mon halt
|
||
(gdb) load nuttx # Re-load code into SRAM
|
||
(gdb) mon reg pc __start # Set PC to __start entry point
|
||
(gdb) file nuttx
|
||
(gdb) b nx_start
|
||
(gdb) c
|
||
|
||
Recovering from bad code in FLASH:
|
||
|
||
In my initial debug effort, I had a lethal bug that I thought had bricked
|
||
the board. It appears that initialization logic put the MAX32660 in a bad
|
||
state so that every time that I reset the board, I would re-enter this
|
||
same bad state and I could not connect the CMSIS-DAP debugger.
|
||
|
||
I was able to recover. I jumpered GND to RSTn the used the MBED MSC
|
||
interface to copy a known safe 'SysTick' demo program. The copy hung and
|
||
timed out with an error message. I yanked the jumper off RSTn and asked
|
||
to re-try copy. It continued to burn the safe code demo! I fixed it!
|
||
too much drama.
|