nuttx/configs/max32660-evsys/README.txt

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.

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 os_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 os_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.