Bug #4146

SIMtrace2 board RMA

Added by tsaitgaist 2 months ago. Updated about 1 month ago.

Target version:
Start date:
Due date:
% Done:



A customer returned a broken SIMtrace2 board for analysis

P1150077.JPG View P1150077.JPG 4.21 MB tsaitgaist, 08/08/2019 04:49 PM
P1150075.JPG View P1150075.JPG 4.73 MB tsaitgaist, 08/08/2019 04:49 PM
simtrace2-dump.bin simtrace2-dump.bin 256 KB tsaitgaist, 08/08/2019 05:14 PM


#1 Updated by tsaitgaist 2 months ago


there is not apparent exterior physical damage

#2 Updated by tsaitgaist 2 months 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.

#3 Updated by tsaitgaist 2 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 2 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 2 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 2 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:
DFU bootloader:


command to flash DFU bootloader using SAM-BA:
bossac --port /dev/ttyACM0 --erase --write simtrace-dfu-flash-latest.bin  --verify --boot=1

trace firmware:

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

#8 Updated by tsaitgaist 2 months ago

  • % Done changed from 80 to 90

the ERASE pin will be disable after boot with the following change:
this will prevent accidental erase of the flash

#9 Updated by tsaitgaist 2 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

BFAR=e000ed38, CFSR=00010000, HFSR=40000000
DFSR=00000000, AFSR=00010000, SHCSR=00000000

BFAR=e000ed38, CFSR=00040400, HFSR=40000000
DFSR=00000000, AFSR=00040400, SHCSR=00000000

BFAR=308801d8, CFSR=000c8600, HFSR=40000000
DFSR=00000000, AFSR=000c8600, SHCSR=00000000

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 about 1 month ago

  • Status changed from New to Resolved
  • % Done changed from 90 to 100

customer could successfully reflash the board using the rewritten guide:
the boards work again.
the jumpers are marked as Do Not Place (DNP) in the renewed schematic v1.5 of SIMtrace hardware:

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)