SIMtrace2 board RMA
A customer returned a broken SIMtrace2 board for analysis
#3 Updated by tsaitgaist 4 months 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
#4 Updated by tsaitgaist 4 months ago
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.
#5 Updated by tsaitgaist 4 months 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.
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.
#6 Updated by tsaitgaist 4 months 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
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
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.
#7 Updated by tsaitgaist 4 months 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.
#9 Updated by tsaitgaist 3 months 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?
#10 Updated by tsaitgaist 2 months 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