SIM card related Projects » osmo-ccid-firmware

I am using the latest firmware 0.2.67-30c2

This is surprising as we did do a lot of parallel slot CCID stress testing of all the slots during R&D. We were using TTCN3 based tests, as far as I recall. Note that I'm not contesting your findings, I'm just surprised that we didn't see that in our CCID tests in the psat.

I am also surprised.
It is easy for me to reproduce with my sysmoOCTSIM.

I propose to configure a setup on your side so you can investigate what is happening between the reader and the card to generate the error. I do not have the hardware to spy the reader/card communication.

It is not always the first slot that does not fail and continue to work.
In a new test I used slots 0, 1 and 2. Slot 1 failed first, then slot 0.

I suspect a problem with the power supply of my sysmoOCTSIM.
I note that when I connect the power cable no LED blinks. I think it was the case before but I am not sure.
Also there is a 9th LED on the left of the first slot. This LED is never ON. I don't remember if the LED was ON before.
What is this LED used for?

I also got kernel errors and a non-responsive reader.
For example while disconnecting and reconnecting the reader I got

[ 1150.312814] usb 1-1: new full-speed USB device number 34 using xhci_hcd
[ 1150.441087] usb 1-1: device descriptor read/64, error -71
[ 1150.676797] usb 1-1: device descriptor read/64, error -71
[ 1150.912863] usb 1-1: new full-speed USB device number 35 using xhci_hcd
[ 1151.041093] usb 1-1: device descriptor read/64, error -71
[ 1151.276807] usb 1-1: device descriptor read/64, error -71
[ 1151.384860] usb usb1-port1: attempt power cycle
[ 1151.796895] usb 1-1: new full-speed USB device number 36 using xhci_hcd
[ 1151.797145] usb 1-1: Device not responding to setup address.
[ 1152.004969] usb 1-1: Device not responding to setup address.
[ 1152.212893] usb 1-1: device not accepting address 36, error -71
[ 1152.341157] usb 1-1: new full-speed USB device number 37 using xhci_hcd
[ 1152.341382] usb 1-1: Device not responding to setup address.
[ 1152.549045] usb 1-1: Device not responding to setup address.
[ 1152.757106] usb 1-1: device not accepting address 37, error -71
[ 1152.757234] usb usb1-port1: unable to enumerate USB device
[ 1169.513165] usb 1-1: new full-speed USB device number 38 using xhci_hcd
[ 1184.917783] usb 1-1: device descriptor read/64, error -110
[ 1202.881847] usb 1-1: new full-speed USB device number 39 using xhci_hcd
[ 1218.458303] usb 1-1: device descriptor read/64, error -110
[ 1234.070537] usb 1-1: device descriptor read/64, error -110
[ 1234.306230] usb 1-1: new full-speed USB device number 40 using xhci_hcd
[ 1249.686428] usb 1-1: device descriptor read/64, error -110
[ 1262.558462] usb 1-1: new full-speed USB device number 41 using xhci_hcd
[ 1262.708678] usb 1-1: New USB device found, idVendor=1d50, idProduct=6141, bcdDevice= 0.00
[ 1262.708683] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=7
[ 1262.708687] usb 1-1: Product: sysmoOCTSIM 0.2.67-30c2
[ 1262.708689] usb 1-1: Manufacturer: sysmocom - s.f.m.c. GmbH
[ 1262.708691] usb 1-1: SerialNumber: df4be7f03335355320202034433b15ff
[ 1262.711970] cdc_acm 1-1:1.1: ttyACM0: USB ACM device

I also note that I can use the reader if I connect only the USB cable but not the power cable.
I can communicate with 1 card with no problem.
If I try to use 2 cards it works and then I get the error I described above: the reader returns FE for one slot.
It is not surprising if the reader has not enough power to use 2 cards at the same time.

How can I check the power supply I use is working correctly?
I am not a electronic guy. I have no voltmeter for example. Sorry.

In practice the external PSU is not really required, it is only necessary in case you use all 8 slots with a worst case per-sim power draw of 120mA or something like that, but even in that case most host ports (not switchable OTG!) will silently deliver much more current and don't even complain about it. It mostly exists to be USB spec compliant. For 2 sim cards USB should be enough, there is no way that can exceed the 500mA, because even in short circuit conditions the sim driver chip will just switch off the slot power.

can you please replace the usb-cable and retry? i've seen similar issues with different boards which were only a broken cable.

roh can you please check the expected LED behavior when only the PSU is connected?

We can certainly ship another power supply to Ludovic, if this is the problem.

rousseau, if you meanwhile have any other power supply with 5V and > 500mA with a matching connector (center plus, but this is standard these days), feel free to give it a try.

i just checked with firmware from today and latest bootloader:

with only the psu connected it doesn't matter at all and the led stays off. only a small green led on the pcb (not visible with case) is on.

when the button was kept pressed while power was plugged (usb or external) the device is in the dfu-loader. as soon as the usb gets enumerated the led goes green in case we are in the bootloader.

the behavior of this led is completely fw controlled, so i guess Hoernchen can tell us more details.

I have power supply units with the "possibly" good connector but they deliver 10V or 12V.
I don't think that is a good idea to connect them to the sysmoOCTSIM :-)

I have a PSU for 5V but the connector is miro-USB (I used it to power a Raspberry Pi).

I think I have other USB cables to replace the current one and make new tests. I will add my results here.

PS: sorry for the delay. I do not get any email notification when the ticket is updated. I don't know it that is expected.

Dear Ludovic,

On Fri, Nov 05, 2021 at 03:19:24PM +0000, rousseau wrote:

I have power supply units with the "possibly" good connector but they deliver 10V or 12V.
I don't think that is a good idea to connect them to the sysmoOCTSIM :-)

no, that's not a good idea.

I think I have other USB cables to replace the current one and make new tests. I will add my results here.

I think it's best to wait with any further development activity until sysmocom has investigated
this further. We are extremely overloaded, but I would have expected Hoernchen to be
able to comment at least once on this issue within 7 days.

PS: sorry for the delay. I do not get any email notification when the ticket is updated. I don't know it that is expected.

Hi Ludovic,

it is because your ISP considers those notifications as spam and rejects them. See below
line from our mail server log.

Nov 5 15:19:25 lists postfix/smtp⁵⁷⁴¹⁵: 9F7E2216782: to=<ludovic.rousseau+osmocom@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=0.59, delays=0.27/0.01/0.22/0.1, dsn=5.0.0, status=bounced (host mx1.free.fr[212.27.48.7] said: 550 spam detected (in reply to end of DATA command))

maybe you can configure something in the user interface of this ISP to prevent it from
treating osmocom redmine notifications as spam.

Sorry about the lack of a response, I was left with the impression that there were weird PSU issues that obviously need to be solved first before we take a closer look.

I tried with a different USB cable and I have the same problem.

I modified the CCID driver to disable the support of simultaneous CCID commands. In this case I do NOT reproduce the problem. I used 3 cards and run my program to access the 3 cards at the "same time". pcscd uses a lock to serialize the accesses so the performances are not good but I do not have the "Card absent or mute" error from the sysmoOCTSIM reader.

I think it would help if you could configure a setup with one sysmoOCTSIM and 2 or 3 cards on your side.
If I can reproduce the problem then my PSU or USB cable is not at fault. And you will have everything you need to analyze the problem on your side.

Just to be sure I also tried to connect the sysmoOCTSIM to a desktop computer instead of a laptop.
The desktop should provide enough power to the USB interface.

I can still reproduce the problem.
Connecting or not the PSU to the sysmoOCTSIM does not change the result.

I received the new USB cable and PSU.
I tried with the new USB cable (and no PSU connected) and I have the same problem.
I tried with the new USB cable and the new PSU and I also have the same problem.

It looks like the USB cable and the PSU are NOT the cause of the problem.

I really think it would help if it is possible to reproduce the problem on your side. You will then have everything to work on the issue.

Oh, sorry, I missed your update because I was for some reason not added as a watcher..
It's fine, I'll take a look at it now - I've debugged plenty of "weird" issues recently, so it was important to make sure that it was not the PSU/cable first.

Good news. I can't reproduce the problem with this new firmware.
I checked with 3 SIMs at the same time and the total time to dump 1, 2 or 3 SIM is always 24 seconds. So the driver is really talking to the 3 slots at the same time (in parallel).

I don't know why you modified the PPS handling. Now the communication is very slow. We moved from 5 seconds to 24 seconds to dump a SIM card.

This is a workaround for you, so you can look at concurrent access - the problem was related to higher baud rates, and this obviously is not a proper fix, just something that allows you to keep working on the pcscd concurrency topic for now without any weird errors.
In practice the baud rate is not that important anyway, because the long running commands like "run gsm algo"/response keep a slot busy for quite some time, and that is not related to the baud rate at all.

By the way, does the new pcscd allow accessing slots that are powered while other slots are still unpowered/trying different voltages (might be unresponsive, broken, empty sim card holder, ...)?

The new firmware sysmoOCTSIM-0.2.71-ebfc-dirty.bin reports a card present with PC_to_RDR_GetSlotStatus even if no card is inserted in the slot.
This was not the case with the previous firmware.
It is a regression. I don't know if you did it on purpose.

To answer your question: every slot is independent. So yes, it is possible to access a slot while another one is doing something else like power on or power off, etc.

The card presence is now working as expected with the latest firmware.

Now improve the communication speed as it was before and I am happy :-)

Hoernchen do you plan to generate a new firmware with this fix and also the correct (optimised) communication speed between the card and the reader?

The fix, yes, it should be part of the automatic firmware builds by now, the speed, no, not at the current time.