Cause

This issue is due to a lack of bypass capacitance on the output of the bq24230 (the battery charger and power path IC).
Without a high capacitance on the output, the IC is unstable and does not produce a regulated output voltage.

Workarounds

The general principle is to add a suitable bypass capacitor to the output of the bq24230 (U1).
There are several ways to achieve this:

1. Plug in the device. With the board face up and oriented like a capital 'T', touch
   the leads of a large (4.7uF to 47uF) capacitor from GND to the upper pad of either R19 or R20.
   The LEDS should immediately turn on, and the 3.3V power rail should be working.
   Note that because the capacitor is not permanently attached, the power supply may
   occasionally become unstable again, and the process must be repeated.
2. (recommended) Remove R18 and R19. With the board face up and oriented like a capital 'T',
   solder a large (4.7uF to 47uF) capacitor from the rightmost pad of R18 to the upper pad of R19.
   An 0603 capacitor is ideal if possible, since it happens to be the perfect dimensions to bridge the gap.
3. (untested) If no suitable capacitor is on hand, it should be possible to directly apply an input
   voltage that bypasses the power path IC. Solder a wire to the upper pad of R19 (R19 can be removed if desired).
   The input voltage at this point should be between 3.4 V and 5.5 V. The chances of this method succeeding are
   higher if the bq24230 (U1) is removed, and a 0.1uF to 1uF bypass capacitor is applied on the input rail.

/cc @brghena

There are some un-diagnosed, rather serious interactions between RTS3 and the sensor power rail.

To replicate the problem, first install the Tock kernel from master or the bugs/imix-power branch of Tock:

$> cd ${TOCK_BASE}/boards/imix
$> make flash

The, install the imix sensors app:

$> cd ${TOCK_BASE}/boards/imix/apps/sensors
$> make flash

Finally, print the output from the app by running miniterm with DTR inactive (HIGH, attached to SAM4L reset) and RTS active (LOW, default):

$> miniterm2.py --dtr 0 --rts 1 /dev/ttyUSB0

You should get output resembling the following every second or so:

--- forcing DTR inactive
--- forcing RTS active
--- Miniterm on /dev/ttyUSB0  115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
Intensity: 281; Temperature: 23.64; Humidity: 19.60

However, if RTS is forced inactive (HIGH), there is no output:

$> miniterm2.py --dtr 0 --rts 0 /dev/ttyUSB0

Note that the console turns off hardware flow control entirely.

Finally, attaching a patch-wire between NRF_EN and GND (to force the NRF51 on) results in output all of a sudden.

More symptoms

Under mainline kernel, with PB[06] assigned to RTS3, the voltage on NRF_EN and SENSOR_EN are never quite 0V or 3.3V. Instead they are closer to 0.06V and 2.2V, respectively. Removing the assignment of PB[06] to RTS3 (by either leaving it disabled or enabling it as an input, e.g.) results in either 0.04V or 3.2V (which seems reasonable?). The overall problem is not fixed, though, and in fact, it makes --rts 1 stop working and the only way to get any output is to explicitly enable the NRF as well.

From my test, enabling the RNG (by clearing PC19 on the SAM4L) browns out the SMA4L on a patched board of the most recent revision. @shaneleonard any suggestions on how to diagnose further? It might be worth you trying replicate as well, since it's definitely plausible I'm doing something wrong (I just enabled PC19 as an output then cleared it. If I set it instead, no problems--but also no RNG of course).

There is evidence that the radio signal for the RF233 is pretty weak. This might be due to interference from the RNG's ground plane.

The issue @phil-levis commented on in the ADC driver seems to be fixed in Imix now. https://github.com/helena-project/tock/blob/master/chips/sam4l/src/adc.rs#L11 (@shaneleonard let me know if that's right and I'll remove the comment)

However, the pins are still mapped with AD0 -> ADCIFE1, AD1 -> ADCIFE2, etc. Is there any reason that they shouldn't be AD0 -> ADCIFE0, AD1 -> ADCIFE1, etc. instead so that the world makes sense?

On the Firestorm, the FT231's DTR pin is tied to logic that allows flipping the power to the board. On the Imix currently DTS is tied to the SAM4L reset. Is that right? Isn't DTS an input pin for the FTDI chip?

The schematic and associated PDF are not incredibly readable. Should reorganize the components, add descriptive frames, and especially clarify the 'headers' page, which is a mess

It would be good to commit your Eagle libraries to this repo too.

Cause

It is suspected that the solder on the pads of the connector negatively impact the connection enough to
prevent the programmer from sinking enough current to drive the reset line low.

Workaround

Currently unknown.

(I'm not sure there is anything great to do about this)

When I attach a terminal to the FTDI, DTR--which is connected directly to the SAM4L's RESET signal--is pulled low, and the board effectively halts. stormloader relies on this to be able to reset the board, so this behavior is identical on the Firestorm, but it's a huge bummer because it means that typical utilities for connect to a serial port (e.g. miniterm, minicom, screen, etc) don't work by default.

There are currently two workarounds I've found:

1. miniterm2.py takes a --dtr argument which tells it to assert or de-assert the DTR signal. miniterm2.py --dtr 0 /dev/ttyUSB0 115200 works for me. I'm not sure how to do this with other utilities.

2. We can program the FTDI chip to invert the DTR signal, which would allow connecting through a terminal serial applications to work out of the box, but the reset signal will be held low by default, so the board won't run.

How does Arduino manage this? Thoughts?

The SAM4L pins 8 and 97 are not connected to VCC_MCU_3V3. They are instead connected to the decoupling capacitors C19 and C22 without being connected directly to the power net.

This results in a variety of strange behaviors. Essentially, certain peripheral banks in the MCU try to draw power from VDDIO, but instead they are drawing from the charge coincidentally stored in C19 and C22. When C19 and C22 are drained, things stop working.

This error happened because of a nuance with EAGLE. EAGLE should have caught this as a Design Rule error, but due to the specific way the footprint was made, it incorrectly assumed that all of the VDDIO pins were internally connected. Thus, once any of the VDDIO pins (8, 97, 87, or 88) were connected to power, it assumed all four were connected to power, and didn't generate the necessary airwires to connect each pin to power individually.

In the current revision, the RF233 enable pin is tied to ground because of an original misdiagnosis of #7. Since that's now fixed we should re-establish the SAM4L's control over the RF233's enable pin.

• Test that controlling the enable pin from the SAM4L no longer browns out the SAM4L

• If it works, remove the trace/resistor grounding the enable pin.

In order for an application to decide when it's safe to sample the RNG, it needs to monitor the voltage coming out of DC/DC

When connected over the FTDI USB and attempting to program over JLink, JLink complains that it cannot pull RESET low. This is due to the fact that the DTR pin of the FTDI chip is connected directly to RESET instead of being connected via a pullup resistor. Adding a 1K resistor between DTR and RESET fixed this issue on the hail board and fixes it on imix as well. See #13.

Steps to reproduce the error:

1. Power board using the FTDI USB port
2. Connect over JLinkExe
3. Run the reset command (r) in JLinkExe after connecting

JLinkExe will output the following warning:

**************************
WARNING: RESET (pin 15) high, but should be low. Please check target hardware.
**************************

When the resistor is added and the above procedure is repeated, the warning goes away and instead we get a successful result:

Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
Found SWD-DP with ID 0x2BA01477

R6 is a 10k pull up on the nRF SWDCLK line. However, that line should have at most a pull down on it, and it seems like it actually doesn't need anything.

Removing R6 seems to allow BLE to work as expected.

Cause

Reset line on the FTDI side is shorted to ground in an internal layer. :(

Workaround

Cut the trace as shown below so that the FTDI side is disconnected from the MCU side. This will allow the MCU to be programmed using a JLink.

Do you plan to add 10/100M Ethernet support, like in this board https://www.aliexpress.com/item/ATSAM4E16E-ATSAM4-Evaluation-Kit-120MHz-Cortex-M4-Ethernet-USB-UART-CAN-485-TF-NAND-RTC-2/32827008906.html ?

Can someone commit the latest board files? It is difficult to map the software resources provided to userspace to actual pins on the board without the hardware design files.