SIM card related Projects » SIMtrace 2

On Tue, Aug 28, 2018 at 05:01:02PM +0000, mschramm [REDMINE] wrote:

• the planned ATSAM3S4B is not "recomm'd for new designs" according to Microchip. However, there is no EOL PCN for these parts. Kevin and me were thinking of using the ATSAM4S4B which is a pin-compatible "in production" Cortex-M4, this also is cheaper than the SAM3S.

yes, we do have even one or two re-worked SIMtrace2 boards with the
SAM4S, I think one of it is with Kevin. It should not only be
pin-compatible, but also instruction-set, memory-layout and peripheral
compatible. So unless they screwed up something regarding clock or
other low-level initialization, I would expect the same binary to even
work.

• Sylvain's suggestion #1463 (add VCC current sensing circuit/resistor) should be inserted in v2, too (prelim default to 0R). Preferebly with Kelvin contacts! ;)

sure.

• removal of 6pin DEBUG connector: did no one need the FTDI adapter pinout? In that case, I'll simply remove it.

no, we don't need it. OsmocomBB-style 2.5mm jack is standard by now,
and it's not too much to ask people to have such a cable if they like
console UART access

• consider switching from JTAG to SWD header: we can have both - what about a Cortex debug connector (referring the pinout (see image); no need to got to their 0.05” pitch) ?

The "problem" with ARM-JTAG-20 is that it's huge. Most people will
never use it, at programming is done via DFU, and in emergency cases via
SAM-BA. So JTAG is only used by those few that ever hack on the code,
and I think given the lack of contributions over 7 years it's clear
there are only very few people outside the core Osmocom + sysmocom team
who will take advantage of that...

I don't like the SWD connector as it's flimsy and has a small pitch,
either.

I would actually be slightly in favor of TC2050 based JTAG like we have
on a number of other sysmocom boards by now. It's small, has no
connector cost, and we have adapters for it anyway. Sure, it will be
a bit costly for "outside developers" wanting to do low-level JTAG
debugging/tracing, but in the worst case, one can always solder wires to
the pads if looking for a quick and low-cost version.

Not sure how others think about it, but I think at the moment I would
put the "ease of use" for those people first who actually have shown a
track record of working on it, which is "us".

• have real SPDT switch rather than SPST: I'll again use the TS3A5018 for this.

This needs to be discussed with Kevin in detail. I think we might
actually need two of those for all required modes?

• passive tracing: SAM3 + SIM + phone connected at the same time
• card emulation / remsim: SAM3 + phone connected at the same time SIM disconnected
• card reader: SAM3 + SIM connected; phone disconnected
• MITM: SAM3 + SIM connected; SAM3 (other UART) + phone connected

The obvious approach of reaching the above is to have two SPST switches?

• RTC Xtal: pins XIN32 and XOUT32 were designated for other GPIO
  functionality, but will now be freed for slow Xtal.

shouldn't be a big deal

Regarding the backup cap: do you think of a (small) supercap? Then:
what timespan do you need the backup domain and RTC remain valid?

I would not want to have THT or other bulky components by default. not
sure if there are supercaps in SMT that aren't bulky? I think the use
case must be studied further. I would expect that you'd basically
connect some kind of battery to the device, then connect USB at the same
time, set everything up for tracing, and then remove USB. In that
scenario, there's the battery that's buffering the RTC as there's
continous supply voltage. If you then were to disconnect the battery
and later reconnect it, you'd loose time. But even then, it would only
be the absolute time that you loose, you could still have relative
timestamps for all events until you again disconnect the battery.

Thinking about a battery parallel supply however means we should keep
the DC input in addition to the USB jack.

• SPI flash: in the long run not used for logging, only used for version detection - let's find a proper µSD card holder, which is available and has a reasonable part's footprint.

I'm wondering if we didn't already build something with uSD slots and
whether we have library parts. A quick scan of our git repo didn't
flag anything, though.

• version detection: we should introduce a 'version detection' voltage divider on ADx.

ACK.

• two level translator for both USARTs seem to be desirable: their VccA is 3V3 for the ARM, VccB is the SIM voltage actually seen from the phone/modem. This would at least be needed if another idea is still on the list:

yes, I think it's clean to have proper level translation care must be
taken to put it at the right place, see above discussion about 2xSPST,
SPDT, ...

• rigth now, the ARM can decide which power source the SIM should see (3V3 or Vcc_PHONE). Wasn't there that idea to have the ability to change between 1V8, 3V3 and 5V for the SIM when it is not powered by the modem/phone?

I think this is an esoteric feature. If we can get it more or less for
free, fine. But I would guess that 99.9999% of users don't care which
voltage is used - just as long as it works on the protocol level.

We've just seen that in 2018 you can buy new CCID readers that do 5V
only (!)

So I wouldn't invest extra effort into it.

On Thu, Sep 06, 2018 at 12:01:46PM +0000, tsaitgaist [REDMINE] wrote:

the SAM4S doesn't fully work out of the box.

thanks for trying.

what works:
- serial output
- USB enumeration of the trace firmware
- sniffing with host application

I guess that's the most important part.

what does not work:
- DFU flashing: the USB is not enumerated after switching to the bootloader (which cause the watchdog to trigger)

that's interesting. I would not be surprised if flash programming is somehow different.

However, that the DFU firmware doesn't even enumerate is somehwhat odd.

- forcing DFU: pressing on the bootloader button while resetting does not start the DFU bootlaoder

Also that part.

But in any case, I guess it shouldn't be too hard to resolve those issues should we chose to
migrate to SAM4S.

Hi Martin,

On Thu, Sep 06, 2018 at 07:45:41PM +0000, mschramm [REDMINE] wrote:

I'm not particularly a fan of the TC2050. [...]

but me! ;)
I don't share your mechanical concerns: when storing, a programmer should be pulled off the PCBA, IMHO. The metal guides are sanded, and even when trying to insert incorrectly, they don't scratch
the holes, the glass fiber of the FR4 rather 'polishes' those stands / guides. Pin assignment: we used the 'old' Atmel's JTAGICE layout which is reasonable.

I think I made my arguments quite clear. We never saw much contribution from anyone but the
simtrace makers (Kevin and me) over the last 7 or so years of the project. There were probably 2-3
cases where somebody actually contributed to the firmware. And for those few people, I think
buying an adapter cable, or simply soldering a few wires to the pads is acceptable.

We could add the TC-2050 cable (and associated adapter to ARM-20-JTAG) to the sysmocom webshop
to make it easier to obtain everything needed for firmware debugging. However, the cost of it
remains. But I somehow like that idea, as sysmoQMOD users might want that, and also the upcoming
sysmoOCTSIM and possibly more boards will share this connector + pinout. But we can do this
irrespective of what happens on SIMtrace.

To summarize:

• 1.27mm pitch headers are too flimsy/fragile, and you cannot really do THT with them.
• ARM-20-JTAG is too large and occupies too much board surface, unless an edge-launch
  version is used
• TC-2050 requires a special cable

So if Kevin cannot accept/tolerate TC-2050, then we should either go for edge-launch, or for
a completely non-standard "1x5 2.54mm" header pinout that doesn't require that large a footprint

[...] Having one on the card side would provide support and allow "compliance testing" for all voltages (not sure how often this feature would be used, but it can be a nice/selling feature). Not having it would save one translator, and one adjustable voltage regulator (we only need a switch for providing 3.3V)

I don't think we should aim for that feature, see Harald's remark on that above. - But we could measure the voltage used on the SIM (if powered from the phone/modem) when VCC_SIM is connected to a AD input (via a resistive divider), what do you think?

all options are open here. If wanted, we could also use the IC we're planning to use on the sysmoOCTSIM,
which allows voltage switching between 1.8/3/5V and it already contains the level shifter. OF course this
wouldn't allow powering the card at arbitrary non-spec voltages.

Instead of providing a supercap I would only provide a slot for a coin cell (CR2016-CR2032, oder smaller CR1220).
these batteries hold for years/decades (no timespan issue), and the user can choose to insert (or replace) it when required (no charging issue).

There are really tiny supercaps, I thought of something like the DCK or DSK types by Elna, they are reflow-soldering types and provide 0.07 resp. 0.22 Farad. - A good coin cell holder (e.g. not a type that shorts its contacts when no cell is inserted) is close to the price tag of these supercaps. But you are right, at least an additional diode + resistor is needed for charging these caps, another Schottky series diode would also be needed for both solutions.

Let's keep that as an option for further discussion. It would be interesting to compute the
theoretical/expected amount of time such a 0.07 / 0.22 F supercap would keep the RTC running, considering
values from the SAM3S/SAM4S data sheet on the RTC oscillator

After all, the cheapest solution is a simple CR1210 holder like this . However, on these types one contact is always a large PCB pad which connects best when the PCB has ENIG finish, HASL will work but may introduce specific contact problems for the battery. Moreover, because of their battery insertion/removal direction, they have to be close to a corner or an inner area where no other parts are in front.

I don't like battery holders, sorry.

It seems that there is ongoing need to discuss the powering for autonomous usage. ;)

The question is whether you want to fit everything into a kind of "phone sleeve" like demodulate
wants to do. In this case, a USB power bank is much larger and heavier than the target. In that
case, some small li-ion battery would work, but a USB power bank wouldn't.

btw, laforge thought about using 3V as main supply voltage instead of 3V3. Did I get this right, and if yes: Harald, could you please explain the rationale behind this?

The rationale is simple:

• ISO7816 actually specifies the card voltages as 1.8V, 3V and 5V.
• 3.3V is the absolute maximum value if cards are powered by 3V.

All SIM cards must permit 3V operation, so that's the default voltage
for us (unless we have some kind of adjustible SIM power supply
onboard). So rather than always operating at the absolute maximum
rating, we could simply go to the nominal voltage. I don't think the
SAM3S or any of the other devices we have on board care. So this move
would make us a bit more spec compliant.

the reset button was never needed for anything. In the years of using simtrace, it was
always only very accident-prone, i.e. you inadvertently touch the button and have to
start your tracing/task from scratch. very annoying.

To get into SAM-BA bootlodaer on SAM7 (and SAM3) you can simply close the erase jumper,
attach USB, wait some seconds, disconnect USB, remove the jumper and then re-connect USB.

No reset button needed.

The request to add a ERASE button was basically to avoid having to have a jumper and
close/open it. Simply pressing ERASE while connecting the board to USB would then
be sufficient.

But that probably is almost as dangerous. Not quite, as pressing ERASE after power-up /
during runtime is not dangerous. But anyway, let's keep ERASE jumper and remove RESET button.

At this point we should probably also move to a sam4...

On Thu, Nov 17, 2022 at 03:44:41PM +0000, Hoernchen wrote:

At this point we should probably also move to a sam4...

Any specific reason as to why? In theory the same firmware builds
should run on both SAM3S and SAM4S, but when Kevin tested that he ran
into some DFU problems (there's a separate ticket for that).

In any case, I cannot confirm that SAM4S4BA is generally more available
than SAM3S4BA. Right now it is true, Microchip has SAM4S4BA in stock,
but we typically keep hundreds of SAM3S4BA in our inventory at sysmocom
to make sure we can manufacture SIMtrace2 etc.

Right now we have OWHW, QMOD, ngff-cardem and simtrace2 using SAM3S4BA.
If we switch one of them, we'd have to switch all of them.

tsaitgaist wrote in #note-17:

the SAM4S doesn't fully work out of the box.

what works:
- serial output
- USB enumeration of the trace firmware
- sniffing with host application

what does not work:
- DFU flashing: the USB is not enumerated after switching to the bootloader (which cause the watchdog to trigger)
- forcing DFU: pressing on the bootloader button while resetting does not start the DFU bootlaoder

• enumerated as /dev/ttyACM0
• unmodified DFU binary could be flashed via SAM-BA / bossac
  • interestingly the full/combined firmware couldn't be flashed, it reliably aborted after 41%
  • might be an incompatibility with my 2017 version of bossac
  • doesn't matter as the DFU loader could be flashed successfully
• DFU loader enumerates
• unmodified simtrace2 binary appears to have been flashed via DFU / dfu-util
  • unfortunately the memory is 0xffffffff even while our DFU program reports success.

I assume some kind of subtle difference in the flash controller. will investigate.

starting over with a SIMTrace-NG core design derived from the ngff-cardem as discussed. Also, I'd like to integrate the level shifter logic like used in the 'Mega-Simtrace' (the Octsim-tester controller).

• switches will be two CB3Q3244

• I've got four library elements for microSD card holder (1 by 3M, 3 by Würth), but all of them are four to six times the price tag of a W25Q232. Furthermore, they don't have a /WP input, so e.g. no possibility to protect them from corruption in case of power glitches. Do we really want logging on SD cards?

• the SIM Vcc switches FPF2109 fade EOL, but we're going to replace them with MIC2091-1 . They can deal with 1,8V to 5,5V .

• we had the idea of using the NCN8025 card front-end:
  >[NCN8025] allows voltage switching between 1.8/3/5V and it already contains the level shifter. Of course this wouldn't allow powering the card at arbitrary non-spec voltages.
  The IC isn't in stock @Digikey, while other distributors stock it (as well as sysmocom). What is the current opinion here: use this IC, or the 'conventional' way (e.g. LVC2T45... like in the Octsim-tester controller) ?

• a RTC XTAL is planned, yet we don't have a decision on a Vbackup source.

• besides all mandatory features, a request for SIM CLK counting came up. The SIMTrace-derived Octsim-tester controller features this (HC4040, CBT3252). Do we want to have this integrated?

(CBT3252)

typo: it's of course a CBT3251; there is no CBT3252.

sd cards are a really really really bad idea for devices that can just be turned off and do not have a big smoothing cap on the PSU side that slowly discharges. The sd card writes end up in internal buffers, and then the sd card does some wear levelling magic, which means it takes quite some time until a write is actually commited. Any power loss during that time marks those sectors as read only because they contain damaged data until they are formatted. If you do this too many times without clearing that write only mode by formatting some manufacturers will permanently switch the card to read only mode and it is pretty much dead at that point. This is how the rpi1 and some other sbcs kept killing sd cards. The details vary, depending on card manufacturer and card type, because this is not standardized in any way, and there is no way to fix this in software.

Hoernchen wrote in #note-43:

sd cards are a really really really bad idea for devices that can just be turned off [...]

I would second that. It would be tolerable if we had an independent local power supply via Li-Ion, LiPo or thelike, and a small PMIC w/ battery charger via USB and fail-over.
The current W25Q32 can be replaced with a e.g. W25Q128 (32 MByte), double the price of a W25Q32 , or one third the price of a MicroSD card holder. I'd like to use the combined SO8 footprint for narrow and wide packages and like to stay with a NOR flash IC. This way, one could even populate FRAM there.

mschramm wrote in #note-44:

The current W25Q32 can be replaced with a e.g. W25Q128 (32 MByte), double the price of a W25Q32 , or one third the price of a MicroSD card holder.
I'd like to use the combined SO8 footprint for narrow and wide packages and like to stay with a NOR flash IC. This way, one could even populate FRAM there.

has anybody ever used that flash for anything ever yet?
my impression was, we should, if we keep the layout, put this chip as DNP. no need to generate cost/bom issues for features which nobody uses.

..no. I actually checked my simtrace 2 and was suprised to find a winbond flash chip on it. Looks like the simtrace 1 had firmware that used it (?) but I am not aware of any code for the simtrace 2.

On Mon, Oct 23, 2023 at 06:48:36PM +0000, roh wrote:

has anybody ever used that flash for anything ever yet?

yes, in the very early days of SIMtrace1 there was somebody reporting using it with a modified firmware.

my impression was, we should, if we keep the layout, put this chip as DNP. no need to generate cost/bom issues for features which nobody uses.

I don't think that 1 EUR is going to make a difference, so I'd keep it.