I am trying to develop Java Card applications. I am using the newest Eclipse 4.4.2, the Java Card SDK 2.2.2, and the Eclipse Java Card Development Environment (EclipseJCDE). Previously I succeeded with the JCWDE Java Card Emulator and the APDU Tool. I was using a very basic applet that I had found in this tutorial (youtube: Tutorial 1 Java Card Master SID ENSET 20 01 14) and it was working flawlessly. What I would like to do is deploy this applet to a real Java Card (brand new Gemalto IDCore 3010), but I haven't managed so far.
I have found also this clever and straightforward tutorial (youtube:Developing on Java Card JCOP Hardware Tutorial w/ Python) about deploying applets on real cards, but it just doesn't work for me. After creating a very basic applet it uses a so called Global Platform Pro command line interface - very handy indeed - to load and manage the applets. Sadly I fail right after the first command, which would dump the ATR of the smartcard (gp -i command). This is the error message that I get after re-running the command with -d -v -i switches:
C:\JavaCard\GP>gp -d -v -i
# Detected readers from SunPCSC
[*] OMNIKEY AG Smart Card Reader USB 0
SCardConnect("OMNIKEY AG Smart Card Reader USB 0", T=*) -> T=0, 3B7D960000803180
65B0831111AC83009000
SCardBeginTransaction("OMNIKEY AG Smart Card Reader USB 0")
Reader: OMNIKEY AG Smart Card Reader USB 0
ATR: 3B7D96000080318065B0831111AC83009000
More information about your card:
http://smartcard-atr.appspot.com/parse?ATR=3B7D96000080318065B0831111AC83009
000
A>> T=0 (4+0000) 00A40400 00
A<< (0027+2) (646ms) 6F198408A000000018434D00A50D9F6E061291518101009F6501FF 9000
Auto-detected ISD AID: A000000018434D00
***** Card info:
A>> T=0 (4+0000) 80CA9F7F 00
A<< (0045+2) (12ms) 9F7F2A40705072129151810100927100004DCDC6C0033201190333011903
340119000000610000000000000000 9000
Card CPLC:
ICFabricator: 4070
ICType: 5072
OperatingSystemID: 1291
OperatingSystemReleaseDate: 5181
OperatingSystemReleaseLevel: 0100
ICFabricationDate: 9271
ICSerialNumber: 00004DCD
ICBatchIdentifier: C6C0
ICModuleFabricator: 0332
ICModulePackagingDate: 0119
ICCManufacturer: 0333
ICEmbeddingDate: 0119
ICPrePersonalizer: 0334
ICPrePersonalizationEquipmentDate: 0119
ICPrePersonalizationEquipmentID: 00000061
ICPersonalizer: 0000
ICPersonalizationDate: 0000
ICPersonalizationEquipmentID: 00000000
***** CARD DATA
A>> T=0 (4+0000) 80CA0066 00
A<< (0000+2) (5ms) 6A88
NO CARD DATA
***** KEY INFO
A>> T=0 (4+0000) 80CA00E0 00
A<< (0020+2) (11ms) E012C00401FF8110C00402FF8110C00403FF8110 9000
SCardEndTransaction()
SCardDisconnect("OMNIKEY AG Smart Card Reader USB 0", false)
Exception in thread "main" java.lang.RuntimeException: pro.javacard.gp.GPKeySet$
GPKey currently only support DES and AES keys
at pro.javacard.gp.GPKeySet$GPKey.<init>(GPKeySet.java:80)
at pro.javacard.gp.GPData.get_key_template_list(GPData.java:145)
at pro.javacard.gp.GlobalPlatform.getKeyInfoTemplate(GlobalPlatform.java
:268)
at pro.javacard.gp.GPData.print_card_info(GPData.java:260)
at pro.javacard.gp.GPTool.main(GPTool.java:339)
The other command that would list what is on the card returns an even worse error message:
pro.javacard.gp.GPException: STRICT WARNING: Card cryptogram invalid!
Card: 6B7F3BA2EF7DFC99
Host: 0FCFF9EDF25027BA
!!! DO NOT RE-TRY THE SAME COMMAND/KEYS OR YOU MAY BRICK YOUR CARD !!!
at pro.javacard.gp.GlobalPlatform.printStrictWarning(GlobalPlatform.java
:184)
at pro.javacard.gp.GlobalPlatform.openSecureChannel(GlobalPlatform.java:
513)
at pro.javacard.gp.GPTool.main(GPTool.java:371)
Since this Global Platform Pro was not working, I tried working with the less manageable standard Global Platform Interface (sourceforge: GPShell), but without any luck. Even when I tried to run their sample scripts that were given originally, I got the same error message. Having run the GPShell.exe list.txt for example (that would list the applets on the card), I got the output that the application to be selected could not be found, which I don't understand.
I copy the source code here just in case, but that shouldn't be the problem as it worked with the emulator:
package jctest;
import javacard.framework.APDU;
import javacard.framework.Applet;
import javacard.framework.ISO7816;
import javacard.framework.ISOException;
public class JCTest extends Applet {
private byte counter = 0;
private final static byte CLS = (byte) 0xB0;
private final static byte INC = (byte) 0x00;
private final static byte DEC = (byte) 0x01;
private final static byte GET = (byte) 0x02;
private final static byte INIT = (byte) 0x03;
private JCTest() {
}
public static void install(byte bArray[], short bOffset, byte bLength) throws ISOException {
new JCTest().register();
}
public void process(APDU apdu) throws ISOException {
if (this.selectingApplet())
return;
byte[] buffer = apdu.getBuffer();
if (buffer[ISO7816.OFFSET_CLA] != CLS)
ISOException.throwIt(ISO7816.SW_CLA_NOT_SUPPORTED);
switch (buffer[ISO7816.OFFSET_INS]) {
case INC:
++counter;
break;
case DEC:
--counter;
break;
case GET:
buffer[0] = counter;
apdu.setOutgoingAndSend((short) 0, (short) 1);
break;
case INIT:
apdu.setIncomingAndReceive();
counter = buffer[ISO7816.OFFSET_CDATA];
break;
}
}
}
After many days of trying I am sort of desperate that I can't make my brand new Java Cards work. When I insert the card into the reader, the computer only recognizes that, but not the card itself since it doesn't find a driver (I also couldn't find one, but I think that it is not essential to make things work). The task is supposed to be very simple, I just want to use an already working applet on a real Java Card. What is wrong? What am I missing?
After having finally run the gp -i command successfully, this is what I get as the output for the command: gp -visa2 -key 47454D5850524553534F53414D504C45 -unlock -virgin -d -v
C:\JavaCard\GP>gp -visa2 -key 47454D5850524553534F53414D504C45 -unlock -virgin -
d -v
# Detected readers from SunPCSC
[*] OMNIKEY CardMan 3x21 0
SCardConnect("OMNIKEY CardMan 3x21 0", T=*) -> T=0, 3B7D96000080318065B0831111AC
83009000
SCardBeginTransaction("OMNIKEY CardMan 3x21 0")
Reader: OMNIKEY CardMan 3x21 0
ATR: 3B7D96000080318065B0831111AC83009000
More information about your card:
http://smartcard-atr.appspot.com/parse?ATR=3B7D96000080318065B0831111AC83009
000
A>> T=0 (4+0000) 00A40400 00
A<< (0027+2) (645ms) 6F198408A000000018434D00A50D9F6E061291518101009F6501FF 9000
Auto-detected ISD AID: A000000018434D00
A>> T=0 (4+0008) 80500000 08 0681B19093C4A93B 00
A<< (0028+2) (72ms) 4D00927100004DD4C6C0FF01E87D06549F536080A8D1AB091B6BBE07 900
0
Host challenge: 0681B19093C4A93B
Card challenge: E87D06549F536080
Card reports SCP01 with version 255 keys
Master keys:
Version 0
ENC: Ver:0 ID:0 Type:DES3 Len:16 Value:47454D5850524553534F53414D504C45
MAC: Ver:0 ID:0 Type:DES3 Len:16 Value:47454D5850524553534F53414D504C45
KEK: Ver:0 ID:0 Type:DES3 Len:16 Value:47454D5850524553534F53414D504C45
Diversififed master keys:
Version 0
ENC: Ver:0 ID:0 Type:DES3 Len:16 Value:5B9387DE5E618B12760EBE6037B077AC
MAC: Ver:0 ID:0 Type:DES3 Len:16 Value:5454366589B6AE522F58EE7072C101DF
KEK: Ver:0 ID:0 Type:DES3 Len:16 Value:72590E8782F97E80406E4B66199B7CB2
Derived session keys:
Version 0
ENC: Ver:0 ID:0 Type:DES3 Len:16 Value:87B5171538F81656E88F60D4818CEB8A
MAC: Ver:0 ID:0 Type:DES3 Len:16 Value:E9E45A4046E1316200E9E1787A7E9CD0
KEK: Ver:0 ID:0 Type:DES3 Len:16 Value:72590E8782F97E80406E4B66199B7CB2
Verified card cryptogram: A8D1AB091B6BBE07
Calculated host cryptogram: 8E1CE84781FA24C3
A>> T=0 (4+0016) 84820100 10 8E1CE84781FA24C34BEFC7F70A76E60F
A<< (0000+2) (36ms) 9000
A>> T=0 (4+0008) 84CA00E0 08 E59D6ECDF1B764ED 00
A<< (0020+2) (13ms) E012C00401FF8110C00402FF8110C00403FF8110 9000
Replace: false
PUT KEY:Ver:1 ID:1 Type:DES3 Len:16 Value:404142434445464748494A4B4C4D4E4F
PUT KEY:Ver:1 ID:2 Type:DES3 Len:16 Value:404142434445464748494A4B4C4D4E4F
PUT KEY:Ver:1 ID:3 Type:DES3 Len:16 Value:404142434445464748494A4B4C4D4E4F
A>> T=0 (4+0008) 84CA00E0 08 2B4AD25011601191 00
A<< (0020+2) (13ms) E012C00401FF8110C00402FF8110C00403FF8110 9000
A>> T=0 (4+0075) 84D80081 4B 0180100F8DB2F2600B53F9002C36CB377D55AF038BAF4780100
F8DB2F2600B53F9002C36CB377D55AF038BAF4780100F8DB2F2600B53F9002C36CB377D55AF038BA
F47B387704000A3A1AA
A<< (0000+2) (49ms) 6A80
pro.javacard.gp.GPException: PUT KEY failed SW: 6A80
at pro.javacard.gp.GlobalPlatform.check(GlobalPlatform.java:1092)
at pro.javacard.gp.GlobalPlatform.putKeys(GlobalPlatform.java:993)
at pro.javacard.gp.GPTool.main(GPTool.java:555)
Solution: A new GlobalPlatformPro release was necessary for this specific Gemalto card.
The command that lists the applets on the card:
gp -visa2 -key 47454D5850524553534F53414D504C45 -l
Mutual authentication is a mandatory step for uploading and installing applets on smart cards(And also for listing installed applets and packages). Different cards use different cryptigraphy algoritms to do this mutual authentication procedure. It seems that your card using an algorithm that the GlobalPlatformPro does not supporting it. You must take a look at the card's datasheet to see which algorithm your card use.
About the GPShell :
There is an entity on the cards that is named "Security Domain". This entity is responsible for loading, intalling and listing applets. It has an AID and you must select it by Select APDU command. There is an AID in the list.txt script and you must replace it with the AID of the SD of your card.
And about the driver alert: It's OK! I have the same pop up alert when I insert my card in the reader, but everything works fine.
Finally, please don't try to test other tools in such this way! 10 failure in mutual authentication in a row, make the card locked.(not useable anymore).
GlobalPlatformPro README has a well-placed (well-hidden?) hint on this one:
Set the default 40..4F keys to a card that uses VISA2 diversification
with the well-known mother key on a Gemalto card:
gp -visa2 -key 47454D5850524553534F53414D504C45 -unlock
But keep in mind, that you need to know the keying material. The hints are only for well-known public cases.
Related
I want to use a GPIO pin as a new chip select for SPI on an Up Squared board. The Up squared uses an Intel Pentium N4200, so it's a x86 machine. I have managed to this on a Raspberry Pi by using Device Tree Overlays but as this is an x86 machine I may have to use ACPI overlays.
The Up squared has two spi available and they propose here to use ACPI overlays, this repo, which actually works very well. Below one of the asl files they use
/*
* This ASL can be used to declare a spidev device on SPI0 CS0
*/
DefinitionBlock ("", "SSDT", 5, "INTEL", "SPIDEV0", 1)
{
External (_SB_.PCI0.SPI1, DeviceObj)
Scope (\_SB.PCI0.SPI1)
{
Device (TP0) {
Name (_HID, "SPT0001")
Name (_DDN, "SPI test device connected to CS0")
Name (_CRS, ResourceTemplate () {
SpiSerialBus (
0, // Chip select
PolarityLow, // Chip select is active low
FourWireMode, // Full duplex
8, // Bits per word is 8 (byte)
ControllerInitiated, // Don't care
1000000, // 10 MHz
ClockPolarityLow, // SPI mode 0
ClockPhaseFirst, // SPI mode 0
"\\_SB.PCI0.SPI1", // SPI host controller
0 // Must be 0
)
})
}
}
}
I compiled this file using
$ sudo iasl spidev1.0.asl > /dev/null
$ sudo mv spidev1.0.asl /lib/firmware/acpi-upgrades
$ sudo update-initramfs -u -k all
Then I reboot an I can see a device and communicate through it.
up#up:~$ ls /dev/spi*
/dev/spidev1.0
Thus, I decided to write my own overlay based on themeta-acpi samples from intel and I wrote this:
/*
* This ASL can be used to declare a spidev device on SPI0 CS2
*/
DefinitionBlock ("", "SSDT", 5, "INTEL", "SPIDEV2", 1)
{
External (_SB_.PCI0.SPI1, DeviceObj)
External (_SB_.PCI0.GIP0.GPO, DeviceObj)
Scope (\_SB.PCI0.SPI1)
{
Name (_CRS, ResourceTemplate () {
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
"\\_SB.PCI0.GIP0.GPO", 0) {
22 // pin 22 is BCM25 or 402 in linux
}
})
Name (_DSD, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "compatible", "spidev" }, // not sure if this is needed
Package () {
"cs-gpios", Package () {
0,
0,
^SPI1, 0, 0, 0, // index 0 in _CRS -> pin 22
}
},
}
})
Device (TP2) {
Name (_HID, "SPT0001")
Name (_DDN, "SPI test device connected to CS2")
Name (_CRS, ResourceTemplate () {
SpiSerialBus (
2, // Chip select
PolarityLow, // Chip select is active low
FourWireMode, // Full duplex
8, // Bits per word is 8 (byte)
ControllerInitiated, // Don't care
1000000, // 10 MHz
ClockPolarityLow, // SPI mode 0
ClockPhaseFirst, // SPI mode 0
"\\_SB.PCI0.SPI1", // SPI host controller
0 // Must be 0
)
})
}
}
}
But I cannot see the new device. What am I missing?
Edit:
I have modified the code with a code which actually worked. I can see now a device on /dev/spidev1.2.
However, the CS on pin 22 is low all the time which shouldn't be the case. is the number of the pin correct? I'm using pin numbering from here
Edit 2:
Here is the output of my kernel version
Linux up 5.4.65-rt38+ #1 SMP PREEMPT_RT Mon Feb 28 13:42:31 CET 2022 x86_64 x86_64 x86_64 GNU/Linux
I compiled this up linux repository with the RT patch for the right kernel version.
I also installed the upboard-extras package and I'm actually able to communicate through spi for devices /dev/spidev1.0 and /dev/spidev1.1. So I think I have configured the up squared correctly.
There is nongpio file under /sys/class/gpio
up#up:~/aru$ ls /sys/class/gpio
export gpiochip0 gpiochip267 gpiochip310 gpiochip357 gpiochip434 unexport
I can set the GPIO to 1 or 0 and I can see the output on a multimeter, so I think I have right permissions for GPIO.
Edit 3:
Please find in this link the .dat result from acpidump -o up2-tables.dat
I assume that you are using this board. To be able to use I/O pins(i2c, spi etc.), you need to enable them firstly. Easy way to check you already enabled them or not is that typing in terminal:
uname -a
Output of this will be look like:
Linux upxtreme-UP-WHL01 5.4.0-1-generic #2~upboard2-Ubuntu SMP Thu Jul 25 13:35:27 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
In here #2~upboard2-Ubuntu part can be changed accordingto your board type. However if you don't see a similar result, then you didn't configure your board yet. Otherway to check it, go to folder: /sys/class/gpio and check the ngpio file. Inside it, there should be written 28.
To use any I/O pins(i2c, spi etc.), you don't need to change anything on BIOS side, because its coming to you defaultly enabled.
Please check the up-wiki page, and update your board kernel after linux installation. Then your I/O configurations will be enabled. Up-wiki main page.
Currently, I'm facing a weird problem with the STM32. I just generated code with the STM32Cube IDE for the chosen MCU (STM32L031G6). I nearly didn't change anything, except configuring one GPIO as output and trying to let a connected LED blink.
Now the problem:
If I run the code, nothing happens, no blink at all.
Stepping through the code, I can enable the LED once when the WritePin is called. Afterwards, just one step further, the LED is off again, although there is no further WritePin call executed. The LED never gets back on again.
What can be the problem with this code? There is nothing special about it? Did I miss something which is required for generated STM32 code?
For the following code I removed any unused line and comment.
#include "main.h"
void SystemClock_Config(void);
static void MX_GPIO_Init(void);
int main(void) {
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
while(1) {
//HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin);
HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_SET);
HAL_Delay(1000);
HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET);
HAL_Delay(1000);
}
}
void SystemClock_Config(void) {
RCC_OscInitTypeDef RCC_OscInitStruct = {0};
RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_MSI;
RCC_OscInitStruct.MSIState = RCC_MSI_ON;
RCC_OscInitStruct.MSICalibrationValue = 0;
RCC_OscInitStruct.MSIClockRange = RCC_MSIRANGE_6;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_NONE;
if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK) {
Error_Handler();
}
RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
|RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_MSI;
RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1;
RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;
if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_0) != HAL_OK) {
Error_Handler();
}
}
static void MX_GPIO_Init(void) {
GPIO_InitTypeDef GPIO_InitStruct = {0};
__HAL_RCC_GPIOA_CLK_ENABLE();
HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET);
GPIO_InitStruct.Pin = LED_Pin;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
HAL_GPIO_Init(LED_GPIO_Port, &GPIO_InitStruct);
}
void Error_Handler(void) {
__disable_irq();
while (1) {}
}
Update 1:
As seen in the comments the HAL_Delay is not working properly. But how to fix it? And why the code does not let the led flicker when the HAL_Delay is removed?
Update 2:
It is also not possible to use the loop the following way, but the led is not turned on in any way.
while (1) {
HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin);
}
See the following images for the configuration.
Update 3:
When executing the code on the STM32L031G6, the debugger stops pretty soon. Stepping through the code works (sometimes). Here is the debug log when clicking "Run" in the STM32Cube IDE.
SEGGER J-Link GDB Server V7.58 Command Line Version
JLinkARM.dll V7.58 (DLL compiled Nov 4 2021 16:23:13)
Command line: -port 2331 -s -device STM32L031G6 -endian little -speed 4000 -if swd -vd
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: on
Init regs on start: off
Silent mode: off
Single run mode: on
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: STM32L031G6
Target interface: SWD
Target interface speed: 4000kHz
Target endian: little
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link V11 compiled Dec 9 2021 14:14:49
Hardware: V11.00
S/N: 261014681
OEM: SEGGER-EDU
Feature(s): FlashBP, GDB
Checking target voltage...
Target voltage: 3.34 V
Listening on TCP/IP port 2331
Connecting to target...
Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
GDB closed TCP/IP connection (Socket 1132)
Connected to 127.0.0.1
Reading all registers
Read 4 bytes # address 0x1FF000FC (Data = 0x89B8D002)
Read 2 bytes # address 0x1FF000FC (Data = 0xD002)
Received monitor command: WriteDP 0x2 0xF0
O.K.
Received monitor command: ReadAP 0x2
O.K.:0xF0000003
Read 4 bytes # address 0x1FF000E4 (Data = 0x05408A28)
Read 2 bytes # address 0x1FF000E4 (Data = 0x8A28)
Read 4 bytes # address 0x1FF000E4 (Data = 0x05408A28)
Read 2 bytes # address 0x1FF000E4 (Data = 0x8A28)
Reading 32 bytes # address 0xF0000FD0
Connected to 127.0.0.1
Reading all registers
Read 4 bytes # address 0x1FF000FC (Data = 0x89B8D002)
Read 2 bytes # address 0x1FF000FC (Data = 0xD002)
Received monitor command: reset
Resetting target
Downloading 192 bytes # address 0x08000000 - Verified OK
Downloading 6072 bytes # address 0x080000C0 - Verified OK
Downloading 28 bytes # address 0x08001878 - Verified OK
Downloading 8 bytes # address 0x08001894 - Verified OK
Downloading 4 bytes # address 0x0800189C - Verified OK
Downloading 4 bytes # address 0x080018A0 - Verified OK
Downloading 12 bytes # address 0x080018A4 - Verified OK
Writing register (PC = 0x 80006d0)
Starting target CPU...
GDB closed TCP/IP connection (Socket 1128)
Debugger requested to halt target...
...Target halted (PC = 0x1FF000E4)
Reading all registers
Read 4 bytes # address 0x1FF000E4 (Data = 0x05408A28)
Read 2 bytes # address 0x1FF000E4 (Data = 0x8A28)
GDB closed TCP/IP connection (Socket 1152)
Restoring target state and closing J-Link connection...
Shutting down...
On the other hand, the same code works on a STM32L031K6 of the nucleo board with the ST link disconnected.
*Update 4:
Since I'm using a custom board, there may be a flaw in the schematics. I don't see any issues with the circuit, but maybe, you see some. There is no crystal since it shouldn't be required regarding the datasheet. There are internal oszillators available.
The TOUCH net is just a circuit which connects GND to the pin if a button is pressed.
This is the circuit of the STM32L031G6U6.
This is the circuit of the LEDs that should be controlled. In the previous code I just try to control the LED with the net label STATUS_LED. Since I got the LED to blink while stepping through the code, the Mosfet circuit should work.
I'm currently very confused why I got so many problems. I tried a second and third PCB of the same circuit, but the problems are the same.
I figured out, that I cannot use any clock configurations although they are offered by the STM32Cube IDE. Using the MSI just doesn't work for some frequencies. The code will stall in the SystemClock_Config setting the oscillator or the clock.
Why the HAL_Delay sometimes doesn't work and sometimes it does?
Why the system doesn't start at all when trying to run the code (even with everything disconnected and just the power supply reconnecting)?
Why stepping through the code does work but running the code does not?
Problem solved. The Altium package I downloaded was for the wrong package of the STM32L031. It ia for the STM32L031G6U6S and not the STM32L031G6U6.
I'm developing a system that consists of an arduino mkr1000 that I want to send data via wifi to a java server program running in my local network.
Everything works except the main part: data sent by the arduino is sometimes not received by the server...
I'm using the arduino Wifi101 library to connect to my wifi, get a WiFiClient and send data.
The following code is just a example to demonstrate the problem:
for (int i = 0; i < 3; ++i) {
Serial.println(F("Connecting to wifi"));
const auto status = WiFi.begin("...", "...");
if (status != WL_CONNECTED) {
Serial.print(F("Could not connect to WiFi: "));
switch (status) {
case WL_CONNECT_FAILED:
Serial.println(F("WL_CONNECT_FAILED"));
break;
case WL_DISCONNECTED:
Serial.println(F("WL_DISCONNECTED"));
break;
default:
Serial.print(F("Code "));
Serial.println(status, DEC);
break;
}
} else {
Serial.println(F("WiFi status: WL_CONNECTED"));
WiFiClient client;
if (client.connect("192.168.0.102", 1234)) {
delay(500);
client.print(F("Test "));
client.println(i, DEC);
client.flush();
Serial.println(F("Data written"));
delay(5000);
client.stop();
} else {
Serial.println(F("Could not connect"));
}
WiFi.end();
}
delay(2000);
}
The java server is based on Netty but the same thing with manually creating and reading from a Socket yields the same result.
The testing code is pretty standard with only a simple output (note: in Kotlin):
val bossGroup = NioEventLoopGroup(1)
val workerGroup = NioEventLoopGroup(6)
val serverFuture = ServerBootstrap().run {
group(bossGroup, workerGroup)
channel(NioServerSocketChannel::class.java)
childHandler(object : ChannelInitializer<NioSocketChannel>() {
override fun initChannel(ch: NioSocketChannel) {
ch.pipeline()
.addLast(LineBasedFrameDecoder(Int.MAX_VALUE))
.addLast(StringDecoder())
.addLast(object : ChannelInboundHandlerAdapter() {
override fun channelRead(ctx: ChannelHandlerContext, msg: Any) {
println("msg = $msg")
ctx.close()
}
})
}
})
bind(port).sync()
}
The arduino tells that everything is OK (i.e. writing Data written to the serial console for each iteration) but the server sometimes skips individual messages.
Adding the LoggingHandler from Netty tells me in these cases:
11:28:48.576 [nioEventLoopGroup-3-1] WARN i.n.handler.logging.LoggingHandler - [id: 0x9991c251, L:/192.168.0.20:1234 - R:/192.168.0.105:63845] REGISTERED
11:28:48.577 [nioEventLoopGroup-3-1] WARN i.n.handler.logging.LoggingHandler - [id: 0x9991c251, L:/192.168.0.20:1234 - R:/192.168.0.105:63845] ACTIVE
In the cases where the message is received it tells me:
11:30:01.392 [nioEventLoopGroup-3-6] WARN i.n.handler.logging.LoggingHandler - [id: 0xd51b7bc3, L:/192.168.0.20:1234 - R:/192.168.0.105:59927] REGISTERED
11:30:01.394 [nioEventLoopGroup-3-6] WARN i.n.handler.logging.LoggingHandler - [id: 0xd51b7bc3, L:/192.168.0.20:1234 - R:/192.168.0.105:59927] ACTIVE
11:30:01.439 [nioEventLoopGroup-3-6] WARN i.n.handler.logging.LoggingHandler - [id: 0xd51b7bc3, L:/192.168.0.20:1234 - R:/192.168.0.105:59927] READ: 8B
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 54 65 73 74 20 32 0d 0a |Test 2.. |
+--------+-------------------------------------------------+----------------+
11:30:01.449 [nioEventLoopGroup-3-6] WARN i.n.handler.logging.LoggingHandler - [id: 0xd51b7bc3, L:/192.168.0.20:1234 - R:/192.168.0.105:59927] CLOSE
11:30:01.451 [nioEventLoopGroup-3-6] WARN i.n.handler.logging.LoggingHandler - [id: 0xd51b7bc3, L:/192.168.0.20:1234 ! R:/192.168.0.105:59927] READ COMPLETE
11:30:01.453 [nioEventLoopGroup-3-6] WARN i.n.handler.logging.LoggingHandler - [id: 0xd51b7bc3, L:/192.168.0.20:1234 ! R:/192.168.0.105:59927] INACTIVE
11:30:01.464 [nioEventLoopGroup-3-6] WARN i.n.handler.logging.LoggingHandler - [id: 0xd51b7bc3, L:/192.168.0.20:1234 ! R:/192.168.0.105:59927] UNREGISTERED
With my understanding this means that the TCP packets are indeed received but in the faulty cases the IO thread from Netty is waiting to read the TCP data but does never continue...
The same problem exists when trying with a rudimentary python server (just waiting for a connection and printing the received data).
I confirmed the data is sent by using tcpflow on Arch Linux with the arguments -i any -C -g port 1234.
I even tried the server on a Windows 7 machine with the same results (TCP packets confirmed with SmartSniff).
Strangely using a java server to send the data always and reproducibly is received...
Does anybody have any idea to solve the problem or at least how to diagnose?
PS: Maybe it is important to note that with tcpflow (i.e. on linux) I could watch the TCP packets being resent to the server.
Does this mean the server is receiving the packets but not sending an ACK?
SmartSniff didn't show the same behavior (but maybe I used wrong options to display the resent packets).
In the meantime I send messages to acknowledge receiving another message. If the acknowledgement is not received the message is sent again.
For anyone with the same problem:
While testing something different I updated the wifi firmware of the board to the latest version 19.5.2. Since then I haven't noticed any lost data. Maybe this was the problem.
See Check WiFi101 Firmware Version and Firmware and certificates Updater.
Note: I couldn't get the sketches to run with the Arduino IDE but with PlatformIO.
I'm using IdleManager, in Scala, to listen to a Gmail folder.
I already have this props.setProperty("mail.imaps.usesocketchannels", "true")
The main part of my code is like this:
folder.addMessageCountListener(new MessageCountAdapter() {
override def messagesAdded(ev: MessageCountEvent) {
Logger.info("Got " + ev.getMessages.length + " new messages")
idleManager.watch(folder)
}
})
// timeLength = 20 minutes
system.scheduler.schedule(initialDelay = timeLength, interval = timeLength) {
try {
folder.asInstanceOf[IMAPFolder].doCommand(new IMAPFolder.ProtocolCommand() {
def doCommand(p: IMAPProtocol) = {
p.simpleCommand("NOOP", null)
null
}
})
Logger.debug("Continue after sending NOOP")
idleManager.watch(folder)
} catch {
case e: Exception => Logger.error(s"MailHelper: ${e.getMessage}")
}
}
idleManager.watch(folder)
You can see that I let the idleManager continue watching the folder after I get new messages and after I send a NOOP command. A scheduler is created to periodically (currently, once in 20 minutes) send a NOOP command to the server, to keep the connection. My program worked fine, but just for a while.
14 hours after the first call idleManager.watch(folder) and about 12.5 hours after the last email received, I still got the log Continue after sending NOOP, but right after that is an error log MailHelper: Folder is not using SocketChannels.
Could you please help me with this?
Edited:
Thanks #BillShannon for your quick reply. I have updated from v1.5.2 to v1.5.6 and turned on the debug output. I'm sure the Properties object and the "store" instance (created from a Session with the "imaps" protocol) are unchanged.
The error has appeared again. After a call to idleManager.watch(folder), here is the log ([folder] is the imaps protocol string for my folder)
DEBUG IMAP: IdleManager watching [folder]
A385 IDLE
+ idling
DEBUG IMAP: startIdle: set to IDLE
DEBUG IMAP: startIdle: return true
DEBUG IMAP: IdleManager.watch startIdle succeeded for [folder]
DEBUG IMAP: IdleManager selected 0 channels
DEBUG IMAP: IdleManager adding [folder] to selector
DEBUG IMAP: IdleManager waiting...
DEBUG IMAP: IdleManager selected 1 channels
DEBUG IMAP: IdleManager selected folder: [folder]
DEBUG IMAP: handleIdle: set to RUNNING
DEBUG IMAP: IdleManager got exception for folder: [folder], THROW:
javax.mail.FolderClosedException: * BYE JavaMail Exception: java.io.IOException: Connection dropped by server?
at com.sun.mail.imap.IMAPFolder.handleIdle(IMAPFolder.java:3199)
at com.sun.mail.imap.IdleManager.processKeys(IdleManager.java:370)
at com.sun.mail.imap.IdleManager.select(IdleManager.java:281)
at com.sun.mail.imap.IdleManager.access$200(IdleManager.java:137)
at com.sun.mail.imap.IdleManager$1.run(IdleManager.java:164)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
DEBUG IMAP: IdleManager waiting...
20 minutes later, the program sent another "NOOP", the status returned was "OK". And the program called idleManager.watch(folder) once again, here the error log reappeared Folder is not using SocketChannels.
Do you need anything else? Is this an issue with the library?
I'm trying to allocate a sk_buff in my code and then access its skb->data area.
I get a NULL pointer deference.
OpenWRT: Barrier Breaker
Code:
struct sk_buff *skb = NULL;
skb = __dev_alloc_skb(2400,GFP_ATOMIC);
if (skb) {
printk("head= %p \n data= %p \n tail= %p\n end= %p\n len= %d\n", skb->head,skb->data,skb->tail,skb->end,skb->len);
memset(skb->data,0,2400);
}
Dump:
I get the following stack trace:
[ 61.200000] head = ce1dca00
[ 61.200000] data = 00000b20
[ 61.210000] tail = ce1dd360
[ 61.210000] end = ce1dc9c0
[ 61.210000] len = 0
[ 61.210000] Unable to handle kernel NULL pointer dereference at virtual address 00000b20
[ 61.220000] pgd = ce240000
[ 61.220000] [00000b20] *pgd=2e554831, *pte=00000000, *ppte=00000000
[ 61.230000] Internal error: Oops: 817 [#1] SMP ARM
[ 61.230000] Modules linked in: eng qcserial pppoe ppp_async option iptable_nat usb_wwan sierra_net sierra qmi_wwan pppox ppp_generic pl2303 nf_nat_ipv4 nf_conntrack_ipv4 mac80211 ipt_MASQUERADE ftdi_sio ebtable_nat ebtable_filter ebtable_broute cfg80211 cdc_ether ath3k asix xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_id xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_NETMAP xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY usbserial usbnet usbhid ums_usbat ums_sddr55 ums_sddr09 ums_karma ums_jumpshot ums_isd200 ums_freecom ums_datafab ums_cypress ums_alauda ts_kmp ts_fsm ts_bm slhc rfcomm nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4 nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle iptable_filter ipt_REJECT ipt_ECN ip_tables hso hidp hid_generic hci_uart gsc_input ebtables ebt_vlan ebt_stp ebt_snat ebt_redirect ebt_pkttype ebt_mark_m ebt_mark ebt_limit ebt_ip6 ebt_ip ebt_dnat ebt_arpreply ebt_arp ebt_among ebt_802_3 e1000e crc_ccitt compat cdc_wdm cdc_acm btusb bnep bluetooth act_connmark act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress configs hid evdev ledtrig_usbdev xt_LED ledtrig_netdev ledtrig_morse ledtrig_heartbeat ledtrig_gpio batman_adv libcrc32c ip6t_REJECT ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 nfsd nfsv3 nfs bonding ip_gre gre e1000 ifb ip_tunnel tun snd_compress snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_timer snd_rawmidi snd_seq_device snd_hwdep snd soundcore vfat fat ntfs lockd sunrpc nls_iso8859_1 nls_cp437 regmap_spi regmap_i2c regmap_core lzo_decompress lzo_compress rfkill input_core ipv6 arc4 crypto_blkcipher usb_storage uhci_hcd gpio_button_hotplug ext4 crc16 jbd2 mbcache exportfs ptp crc32c crypto_hash [last unloaded: iwlwifi]
[ 61.230000] CPU: 0 PID: 1850 Comm: hostapd Not tainted 3.10.49 #1
[ 61.230000] task: cf97ac60 ti: ce1d6000 task.ti: ce1d6000
[ 61.230000] PC is at __memzero+0x24/0x80
[ 61.230000] LR is at 0x0
[ 61.230000] pc : [<c000c1a4>] lr : [<00000000>] psr: 20000013
[ 61.230000] sp : ce1d7d04 ip : 00000000 fp : ce1d7d2c
[ 61.230000] r10: 00008914 r9 : 00000001 r8 : ce44d400
[ 61.230000] r7 : 00004000 r6 : ce44d400 r5 : 00000008 r4 : ce094560
[ 61.230000] r3 : 00000000 r2 : 00000000 r1 : 000008e0 r0 : 00000b20
[ 61.230000] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 61.230000] Control: 00c5787d Table: 2e24000a DAC: 00000015
I have tried using alloc_skb, dev_alloc_skb also.
ath5k uses __dev_alloc_skb() and successfully uses the returned skb->data on the target platform.
Also the value of skb->data (data = 00000b20) seems to be relative. Is it relative to the skb->head.
Please help.
Thanks
You don't need to use private methods (starting with __), use alloc_skb or dev_alloc_skb (for device drivers, it will be freed automatically) instead.
Also, it is always better to use the provided API for the instance of the sk_buff structure rather than accessing the private fields. See the existing usages for examples: http://lxr.free-electrons.com/ident?i=dev_alloc_skb