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.