RPUpi - a shield for tool-chain at network edge

If the RPUpi were to be integrated onto an RPUno, I would want it tested with a self-test.

https://github.com/epccs/RPUno/tree/master/XcvrTest

That was a lot of effort; the good news is that it should mostly copy to my other boards which I plan to gradually integrate this into (and then ditch all sorts of headers). The 40 pin R-Pi interface will be my path forward, I have grown comfortable with what the R-Pi foundation is doing.

picocom -b 38400 /dev/ttyUSB0
picocom v2.2
...
Terminal ready
RPUpi Transceiver Test date: Jul 11 2019
avr-gcc --version: 5.4.0
I2C provided address 0x31 from manager
SMBUS cmd 0 provided address 49 from manager
MISO loopback to MOSI == HIGH
MISO loopback to MOSI == LOW
SCK with Shutdown loopback == HIGH
I2C Shutdown cmd is clean {5, 1}
SCK with Shutdown loopback == LOW
I2C Shutdown Detect cmd is clean {4, 1}

Testmode: default trancever control bits
I2C Start Test Mode cmd was clean {48, 1}
I2C End Test Mode hex is Xcvr cntl bits {49, 0xD5}
Testmode: read  Xcvr cntl bits {50, 0xE2}
PWR_I /w no load using INTERNAL_1V1: 0.024 A

Testmode: nCTS loopback to nRTS
I2C Start Test Mode cmd was clean {48, 1}
I2C End Test Mode hex is Xcvr cntl bits {49, 0xD5}
Testmode: set  Xcvr cntl bits {51, 0xA2}
Testmode: read  Xcvr cntl bits {50, 0x22}

Testmode: Enable TX pair driver
I2C Start Test Mode cmd was clean {48, 1}
I2C End Test Mode hex is Xcvr cntl bits {49, 0xD5}
Testmode: set  Xcvr cntl bits {51, 0xF2}
Testmode: read  Xcvr cntl bits {50, 0xF2}
PWR_I /w TX pair load: 0.044 A

Testmode: Enable TX & RX(loopback) pair drivers
I2C Start Test Mode cmd was clean {48, 1}
I2C End Test Mode hex is Xcvr cntl bits {49, 0xD5}
Testmode: set  Xcvr cntl bits {51, 0xD1}
Testmode: read  Xcvr cntl bits {50, 0xD1}
PWR_I /w TX and RX pairs loaded: 0.066 A
RX loopback checked

Testmode: Enable DTR pair driver
I2C Start Test Mode cmd was clean {48, 1}
I2C End Test Mode hex is Xcvr cntl bits {49, 0xD5}
Testmode: set  Xcvr cntl bits {51, 0xE6}
Testmode: read  Xcvr cntl bits {50, 0xE6}
PWR_I /w DTR pair load: 0.044 A
[PASS]

First: on ^4 I should have connected the SPI nSS to R-Pi's CE00 pin (oops).

I have been working on the Remote FW for this board, splitting the hulk into smaller parts so they can fit in my brain. Also adding I2C commands that control the bus manager, and trying out the SMBus interface... and then it happened. I did not have a clue what was going on, and it has taken far to long to understand. In short, the R-Pi zero has a problem with clock-stretching.

http://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html

After finally understanding the problem and getting past the sinking feeling, I had an idea.

Interleaving between two buffers (A and B) within the twi ISR used by SMBus interface. And without much testing yet, it seems to have done the trick.  

https://github.com/epccs/RPUpi/commit/089455a040c1aaae76031a735f9558047b78a573#diff-5bd95c1d69122d988a6f85757b66c817

The buffer used by the ISR is swapped after passing it to the user (e.g., with receive callback function). The user receive function runs within the ISR context, but now it can be concise (e.g., save the pointer and byte count). Then all the work can be done outside of ISR context since the buffer is no longer in the risk of being changed, at least until a subsequent receive event when it will be swapped back into service.

https://github.com/epccs/RPUpi/commit/089455a040c1aaae76031a735f9558047b78a573#diff-e5edda6dc80c252451acc1b2be91d078

The quick receive event seems to be tolerated by the R-Pi's clock, but more testing is needed. The handle_smbus function is run in the main loop if there are SMBus bytes available.

https://github.com/epccs/RPUpi/tree/master/Remote

This update really only needed the SPI nSS connected to the Raspberry Pi's CE10 pin. The change of the transceiver was not really important, other than showing a different one that should work (if it works it cost less, but that is likely bait). Removed stuff (terminations, manager ADC6, and ADC7) for simplification. Routed I2C1 to the R-Pi SMBus so only populate this board with a ATmega328pb which was proven with RPUadpt^6 (a 328p will damage the R-Pi SMBus pins).

What do you think about the slogan? I think "Intelligence at the network edge" was Intel's but my interest is more in having the tool-chain at the edge. It means I can bootload directly (not through an adversary) and no network stack so simpler microcontrollers are viable.

Firmware SpiSlv is used to enable the SPI port on a RPUno (ATmega328p).

After loading the firmware on an RPUno and enabling the AVR's SPI I next need the Raspberry Pi SPI hardware setup. Raspian needs its interface master driver enabled (e.g. raspi-config).

Raspibin has an spi group setup in /etc/udev/rules.d/99-com.rules. So I can add my user name to that group for the system to allow me to use the interface.

sudo usermod -a -G spi rsutherland
# logout for the change to take

Next I compile and run spidev_test.c on the Pi with:

wget https://raw.githubusercontent.com/raspberrypi/linux/rpi-3.10.y/Documentation/spi/spidev_test.c
gcc -o spidev_test spidev_test.c
# run with
./spidev_test -s 100000 -D /dev/spidev0.0
./spidev_test -s 500000 -D /dev/spidev0.0
./spidev_test -s 1000000 -D /dev/spidev0.0
./spidev_test -s 2000000 -D /dev/spidev0.0
spi mode: 0
bits per word: 8
max speed: 500000 Hz (500 KHz)
0D FF FF FF FF FF
FF 40 00 00 00 00
95 FF FF FF FF FF
FF FF FF FF FF FF
FF FF FF FF FF FF
FF DE AD BE EF BA
AD F0

Note: The output is offset a byte since it was sent back from the AVR. I see errors at 1MHz and 2MHz. The RPUpi^3 has a 74LVC07 buffer that pulls down through a 10kOhm resistor on SCK and MOSI. The circuit between that resistor and the AVR has some capacitance which will limit the speed (if there is a need for higher speed it may be possible to swap in a 1k resistor).

The hostname of the Pi Zero is pi3, it was the third Pi Zero I have setup (it is a bad hostname). The default bootload address on the RPUftdi (e.g. my multi-drop RS-422 board) is '0', and I have not changed it, I keep the i2c-debug firmware on an ATmega328p board under the RPUftdi for use on my test bench, so I will just upload that same program compiled from the Pi Zero.

rsutherland@pi3:~/Samba/RPUno/i2c-debug $ uname -a
Linux pi3 4.9.41+ #1023 Tue Aug 8 15:47:12 BST 2017 armv6l GNU/Linux
rsutherland@pi3:~/Samba/RPUno/i2c-debug $ make bootload
avr-gcc -Os -g -std=gnu99 -Wall -ffunction-sections -fdata-sections  -DF_CPU=16000000UL   -DBAUD=38400UL -I.  -mmcu=atmega328p -c -o main.o main.c
avr-gcc -Os -g -std=gnu99 -Wall -ffunction-sections -fdata-sections  -DF_CPU=16000000UL   -DBAUD=38400UL -I.  -mmcu=atmega328p -c -o i2c-scan.o i2c-scan.c
avr-gcc -Os -g -std=gnu99 -Wall -ffunction-sections -fdata-sections  -DF_CPU=16000000UL   -DBAUD=38400UL -I.  -mmcu=atmega328p -c -o i2c-cmd.o i2c-cmd.c
avr-gcc -Os -g -std=gnu99 -Wall -ffunction-sections -fdata-sections  -DF_CPU=16000000UL   -DBAUD=38400UL -I.  -mmcu=atmega328p -c -o ../Uart/id.o ../Uart/id.c
avr-gcc -Os -g -std=gnu99 -Wall -ffunction-sections -fdata-sections  -DF_CPU=16000000UL   -DBAUD=38400UL -I.  -mmcu=atmega328p -c -o ../lib/timers.o ../lib/timers.c
avr-gcc -Os -g -std=gnu99 -Wall -ffunction-sections -fdata-sections  -DF_CPU=16000000UL   -DBAUD=38400UL -I.  -mmcu=atmega328p -c -o ../lib/uart.o ../lib/uart.c
avr-gcc -Os -g -std=gnu99 -Wall -ffunction-sections -fdata-sections  -DF_CPU=16000000UL   -DBAUD=38400UL -I.  -mmcu=atmega328p -c -o ../lib/twi.o ../lib/twi.c
avr-gcc -Os -g -std=gnu99 -Wall -ffunction-sections -fdata-sections  -DF_CPU=16000000UL   -DBAUD=38400UL -I.  -mmcu=atmega328p -c -o ../lib/rpu_mgr.o ../lib/rpu_mgr.c
avr-gcc -Os -g -std=gnu99 -Wall -ffunction-sections -fdata-sections  -DF_CPU=16000000UL   -DBAUD=38400UL -I.  -mmcu=atmega328p -c -o ../lib/adc.o ../lib/adc.c
avr-gcc -Os -g -std=gnu99 -Wall -ffunction-sections -fdata-sections  -DF_CPU=16000000UL   -DBAUD=38400UL -I.  -mmcu=atmega328p -c -o ../lib/parse.o ../lib/parse.c
avr-gcc -Wl,-Map,I2c-debug.map  -Wl,--gc-sections  -mmcu=atmega328p main.o i2c-scan.o i2c-cmd.o ../Uart/id.o ../lib/timers.o ../lib/uart.o ../lib/twi.o ../lib/rpu_mgr.o ../lib/adc.o ../lib/parse.o -o I2c-debug.elf
avr-size -C --mcu=atmega328p I2c-debug.elf
AVR Memory Usage
----------------
Device: atmega328p
Program:    8684 bytes (26.5% Full)
(.text + .data + .bootloader)
Data:        375 bytes (18.3% Full)
(.data + .bss + .noinit)
rm -f I2c-debug.o main.o i2c-scan.o i2c-cmd.o ../Uart/id.o ../lib/timers.o ../lib/uart.o ../lib/twi.o ../lib/rpu_mgr.o ../lib/adc.o ../lib/parse.o
avr-objcopy -j .text -j .data -O ihex I2c-debug.elf I2c-debug.hex
rm -f I2c-debug.elf
avrdude -v -p atmega328p -c arduino -P /dev/ttyAMA0 -b 115200 -U flash:w:I2c-debug.hex
avrdude: Version 6.1, compiled on Jul  7 2015 at 10:29:47         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/         Copyright (c) 2007-2014 Joerg Wunsch
         System wide configuration file is "/etc/avrdude.conf"         User configuration file is "/home/rsutherland/.avrduderc"         User configuration file does not exist or is not a regular file, skipping
         Using Port                    : /dev/ttyAMA0         Using Programmer              : arduino         Overriding Baud Rate          : 115200         AVR Part                      : ATmega328P         Chip Erase delay              : 9000 us         PAGEL                         : PD7         BS2                           : PC2         RESET disposition             : dedicated         RETRY pulse                   : SCK         serial program mode           : yes         parallel program mode         : yes         Timeout                       : 200         StabDelay                     : 100         CmdexeDelay                   : 25         SyncLoops                     : 32         ByteDelay                     : 0         PollIndex                     : 3         PollValue                     : 0x53         Memory Detail                 :
                                  Block Poll               Page                       Polled           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
         Programmer Type : Arduino         Description     : Arduino         Hardware Version: 3         Firmware Version: 4.4         Vtarget         : 0.3 V         Varef           : 0.3 V         Oscillator      : 28.800 kHz         SCK period      : 3.3 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "I2c-debug.hex"
avrdude: input file I2c-debug.hex auto detected as Intel Hex
avrdude: writing flash (8684 bytes):
Writing | ################################################## | 100% 1.20s
avrdude: 8684 bytes of flash written
avrdude: verifying flash memory against I2c-debug.hex:
avrdude: load data flash data from input file I2c-debug.hex:
avrdude: input file I2c-debug.hex auto detected as Intel Hex
avrdude: input file I2c-debug.hex contains 8684 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.95s
avrdude: verifying ...
avrdude: 8684 bytes of flash verified
avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0
avrdude: safemode: Fuses OK (E:00, H:00, L:00)
avrdude done.  Thank you.
rsutherland@pi3:~/Samba/RPUno/i2c-debug $ picocom -b 38400 /dev/ttyAMA0
picocom v1.7
port is        : /dev/ttyAMA0
flowcontrol    : none
baudrate is    : 38400
parity is      : none
databits are   : 8
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv
imap is        : omap is        : emap is        : crcrlf,delbs,
Terminal ready
/0/id?
{"id":{"name":"I2Cdebug^1","desc":"RPUno Board /w atmega328p and LT3652","avr-gcc":"4.8"}}
/1/id?
{"id":{"name":"PwrMgt","desc":"RPUno Board /w atmega328p and LT3652","avr-gcc":"4.9"}}
Thanks for using picocom
rsutherland@pi3:~/Samba/RPUno/i2c-debug $ 

So this seems to have worked. The Pi cross compiler for AVR is older than the one on Ubuntu 16.04.

OSHPark did a great job as always, unfortunately, I had a brain fart and forgot that the AVR microcontroller under the shield connects to the RS-422 transceiver through the 74LVC07 buffers I used. I was trying to use the buffers IOFF state to allow the Pi Zero to be powered off without pulling down the RS-422 bus.

When U3 (74LVC07) does not have power the serial RX and TX from shield can not reach the RS-422 transceivers.

For testing, I need to cut U3 power from the PI3V3 node and bridge it to the +3V3 node.

So far this hack is working, but I have another board on the way so this will soon be back on a spin loop thread.