Bug #4146
closedSIMtrace2 board RMA
100%
Description
A customer returned a broken SIMtrace2 board for analysis
Files
Updated by tsaitgaist over 4 years ago
- File P1150075.JPG P1150075.JPG added
- File P1150077.JPG P1150077.JPG added
there is not apparent exterior physical damage
Updated by tsaitgaist over 4 years ago
- % Done changed from 0 to 10
the board draws 30 mA, but no LED is on.
this indicates no short is present and the hardware seems working properly, but the firmware might be missing.
Updated by tsaitgaist over 4 years ago
- % Done changed from 10 to 20
when connected to a computer over USB, it appears as ACM0 device.
the USB descriptor show the SAM-BA bootloader is started:
$ lsusb -d 03eb:6124 -v
Bus 002 Device 021: ID 03eb:6124 Atmel Corp. at91sam SAMBA bootloader
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x03eb Atmel Corp.
idProduct 0x6124 at91sam SAMBA bootloader
bcdDevice 1.10
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0043
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 0
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x00
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Updated by tsaitgaist over 4 years ago
- File simtrace2-dump.bin simtrace2-dump.bin added
There are to reasons why the micro-controller is in SAM-BA bootloader mode:
- the SAM-BA bootloader has been forced (but the SIMtrace firmware is still in flash)
- the flash has been erased
I dumped the flash content:
openocd --file interface/stlink.cfg --command "set CPUTAPID 0x2ba01477" --file target/at91sam3sXX.cfg --command "init" --command "halt" --command "flash read_bank 0 simtrace2-dump.bin" --command "quit"
No strings are present, and all bytes are set to 0xff.
This indicated the flash content has been erased.
The dump is attached.
Updated by tsaitgaist over 4 years ago
- % Done changed from 20 to 50
the flash can be erased the following ways:
- SWD/JTAG command (unlikely in this case)
- pull the ERASE pin high for more than 220 ms (see AT SAM3S datasheet 6.5 ERASE Pin)
the ERASE pin of the board is correctly connected to the ERASE pin of the MCU.
an internal resistor of 100 kOhm pulls the signal low (thus by default the flash will not be erased since it is active high).
There is no additional external resistor.
As documented in the flashing section of the wiki, next to the erase pin of the board there is a 3.3V pin so the user can start the SAM-BA bootloader by connecting/shorting them using a jumper.
wiki: https://osmocom.org/projects/simtrace2/wiki/Flashing#SAMBA
no jumper was present on the pins and the pins were not connected on the board (tested using continuity mode of multimeter).
until now no accidental ERASE has been seen or reported.
I will flash a new firmware to test if the flash gets erased again by itself.
Updated by tsaitgaist over 4 years ago
- % Done changed from 50 to 60
to test the rest of the hardware I flashed the DFU bootloader using SAM-BA, and the trace firmware using DFU.
flashing instruction: https://osmocom.org/projects/simtrace2/wiki/Flashing
DFU bootloader: https://ftp.osmocom.org/binaries/simtrace2/firmware/latest/simtrace-dfu-flash-latest.bin
wget https://ftp.osmocom.org/binaries/simtrace2/firmware/latest/simtrace-dfu-flash-latest.bin
command to flash DFU bootloader using SAM-BA:
bossac --port /dev/ttyACM0 --erase --write simtrace-dfu-flash-latest.bin --verify --boot=1
trace firmware: https://ftp.osmocom.org/binaries/simtrace2/firmware/latest/simtrace-trace-dfu-latest.bin
wget https://ftp.osmocom.org/binaries/simtrace2/firmware/latest/simtrace-trace-dfu-latest.bin
flashing trace firmware using DFU:
dfu-util --device 1d50:60e3 --cfg 1 --alt 1 --reset --download simtrace-trace-dfu-latest.bin
the DFU bootloader and trace firmware started without error.
I was also able to trace/sniff the communication between a Nokia 3310 phone and SuperSIM SIM card.
no defect has been detected on the hardware.
only the firmware has been erased.
Updated by tsaitgaist over 4 years ago
- % Done changed from 60 to 80
I tested the ERASE procedure.
it can be triggered at any point (and not only during boot).
I tried to trigger the ERASE procedure by "shorting" the ERASE pin with the nearby 3.3V using my finger (e.g. simulating what can happen when handling the board). I was not able to trigger the ERASE procedure.
The pin is internally pulled low, but only using a weak 100 kOhm resistor.
Also it need to be pulled high for at least 220 ms and has debouncing protection, make it unlikely a high impedance unstable finger rubbing would trigger it.
But I can't exclude the possibility of it occurring.
I will also disable the ERASE pin in the main firmware to prevent ERASE from happening while the board is powered and operating, but still leave the possibility to ERASE it while powering it up.
Another issue found is that rubbing the TEST pin triggers a Hard Fault, causing the watchdog to reboot the device.
This issue is easily reproducible. Maybe the TEST pin can also be disabled.
To prevent this from happening I recommend to put tape on the both sides of the ERASE/TEST pins.
This also protects it from shorting by other conductors possibly present next/under the SIMtrace board.
Updated by tsaitgaist over 4 years ago
- % Done changed from 80 to 90
the ERASE pin will be disable after boot with the following change: https://gerrit.osmocom.org/c/simtrace2/+/15168
this will prevent accidental erase of the flash
Updated by tsaitgaist over 4 years ago
the TST is pulled low by an internal 15 kOhm resistor.
by rubbing it using a finger I am able to cause HardFault (just a short does not cause it):
BFAR=308801d8, CFSR=00098600, HFSR=40000000 DFSR=00000000, AFSR=00098600, SHCSR=00000000 FORCED NOCP UNDEFINSTR BFARVALID IMPRECISERR PRECISERR BFAR=e000ed38, CFSR=00010000, HFSR=40000000 DFSR=00000000, AFSR=00010000, SHCSR=00000000 FORCED UNDEFINSTR BFAR=e000ed38, CFSR=00040400, HFSR=40000000 DFSR=00000000, AFSR=00040400, SHCSR=00000000 FORCED INVPC IMPRECISERR BFAR=308801d8, CFSR=000c8600, HFSR=40000000 DFSR=00000000, AFSR=000c8600, SHCSR=00000000 FORCED NOCP INVPC BFARVALID IMPRECISERR PRECISERR
the hardfault seems always different and the printed addresses do not match to a firmware line number (GDB did not find it).
the TST pin is not multiplexed and can not be disabled.
the datasheet only mentions this pin is checked during power up (to got to test or FFPI mode), but does not define the behaviour later on.
I did not figure out what exactly is the cause of the HardFault, but since the TST pin is not required anymore I recommend to disconnect it.
this pin is a legacy from the SIMtrace board with ATSAM7S micro-controller to start the SAM-BA bootloader.
mschramm can you simply remove the path between the MCU pin 40 TST and JP1 pin TEST on the board layout for future boards?
Updated by tsaitgaist over 4 years ago
- Status changed from New to Resolved
- % Done changed from 90 to 100
customer could successfully reflash the board using the rewritten guide: https://osmocom.org/projects/simtrace2/wiki/Flashing
the boards work again.
the jumpers are marked as Do Not Place (DNP) in the renewed schematic v1.5 of SIMtrace hardware: https://git.osmocom.org/simtrace/plain/hardware/pcb/schema/SIMtrace.pdf?h=v1.5