Allocating memory in Flash for user data (STM32F4 HAL) - microcontroller

I'm trying to use the internal flash of an STM32F405 to store a bunch of user settable bytes that remain after rebooting.
I'm using:
uint8_t userConfig[64] __attribute__((at(0x0800C000)));
to allocate memory for the data I want to store.
When the program starts, I check to see if the first byte is set to 0x42, if not, i set it using:
HAL_FLASH_Unlock();
HAL_FLASH_Program(TYPEPROGRAM_BYTE, &userConfig[0], 0x42);
HAL_FLASH_Lock();
After that I check the value in userConfig[0] and I see 0x42... Great!
When I hit reset, however, and look at the location again, it's not 0x42 anymore...
Any idea where I'm going wrong? I've also tried:
#pragma location = 0x0800C00
volatile const uint8_t userConfig[64]
but I get the same result..

Okay I found an answer on the ST forums thanks to clive1. This example works for an STM32F405xG.
First we need to modify the memory layout in the linker script file (.ld file)
Modify the existing FLASH and add a new line for DATA. Here I've allocated all of section 11.
MEMORY
{
FLASH (RX) : ORIGIN = 0x08000000, LENGTH = 1M-128K
DATA (RWX) : ORIGIN = 0x080E0000, LENGTH = 128k
...
...
}
Manual for editing linker files on the sourceware website
In the same file, we need to add:
.user_data :
{
. = ALIGN(4);
*(.user_data)
. = ALIGN(4);
} > DATA
This creates a section called .user_data that we can address in the program code.
Finally, in your .c file add:
__attribute__((__section__(".user_data"))) const uint8_t userConfig[64]
This specifies that we wish to store the userConfig variable in the .user_data section and const makes sure the address of userConfig is kept static.
Now, to write to this area of flash during runtime, you can use the stm32f4 stdlib or HAL flash driver.
Before you can write to the flash, it has to be erased (all bytes set to 0xFF) The instructions for the HAL library say nothing about doing this for some reason...
HAL_FLASH_Unlock();
__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_EOP | FLASH_FLAG_OPERR | FLASH_FLAG_WRPERR | FLASH_FLAG_PGAERR | FLASH_FLAG_PGSERR );
FLASH_Erase_Sector(FLASH_SECTOR_11, VOLTAGE_RANGE_3);
HAL_FLASH_Program(TYPEPROGRAM_WORD, &userConfig[index], someData);
HAL_FLASH_Lock();

Related

decode register to 32bit float big endian in python code on raspberry pi 3B with python library pymodbus2.5.3

I'm trying to get the data stream of a sensor transmitter that uses the modbus rtu communication protocol on my raspberry pi 3B. I'm able to get the data with the pymodbus2.5.3 library.
For this I use this code:
from pymodbus.client.sync import ModbusSerialClient # Import the pymodbus library part for syncronous master (=client)
client = ModbusSerialClient(
method='rtu', #Modbus Modus = RTU = via USB & RS485
port='/dev/ttyUSB0', #Connected over ttyUSB0, not AMA0
baudrate=19200, #Baudrate was changed from 38400 to 19200
timeout=3, #
parity='N', #Parity = None
stopbits=2, #Bites was changed from 1 to 2
bytesize=8 #
)
if client.connect(): # Trying to connect to Modbus Server/Slave
#Reading from a holding register
res = client.read_holding_registers(address=100, count=8, unit=1) #Startregister = 100, Registers to be read = 8, Answer size = 1 byte
if not res.isError(): #If Registers don't show Error
print(res.registers) #Print content of registers
else:
print(res) #Print Error Message, for meaning look at (insert git hub)
else: #If not able to connect, do this
print('Cannot connect to the Transmitter M80 SM and Sensor InPro 5000i.')
print('Please check the following things:')
print('Does the RS485-to-USB Adapter have power? Which LEDs are active?')
print('Are the cables connected correctly?')
And get the following output:
[15872, 17996, 16828, 15728, 16283, 45436, 16355, 63231]
With the help of the Modbus Poll and Slave Programms I know that those results should decoded be:
[0.125268, --, 23.53, --, 1.21094, --, 1.77344, --]
To get to the right results I tried the command that the pymodbus github suggests .decode():
res.decode(word_order = little, byte_order = little, formatters = float64)
[I know that those aren't the needed options but I copied the suggested github code to check if it works.]
After putting the code segment into the code the changed part looks like this:
if not res.isError(): #If Registers don't show Error
res.decode(word_order = little, byte_order = little, formatters = float64)
print(res.registers) #Print content of registers
else:
print(res) #Print Error Message, for meaning look at (insert git hub)
When I run this code, I get the following output, that traces to the decoding segment:
NameError: name 'little' is not defined
After this, I imported also the pymodbus part translation. But it showed the same output.
How can I decode my incoming data?
You can use BinaryPayloadDecoder to help decoding your payload, here is a simplified example, change Endian.Big and Endian.Little if needed.
if client.connect(): # Trying to connect to Modbus Server/Slave
#Reading from a holding register
res = client.read_holding_registers(address=100, count=8, unit=1) #Startregister = 100, Registers to be read = 8, Answer size = 1 byte
# ====== added code start ======
decoder = BinaryPayloadDecoder.fromRegisters(res.registers, Endian.Little, wordorder=Endian.Little)
first_reading = decoder.decode_32bit_float()
second_reading = decoder.decode_32bit_float()
# ====== added code end ======
if not res.isError(): #If Registers don't show Error
print(res.registers) #Print content of registers
else:
print(res) #Print Error Message, for meaning look at (insert git hub)
Remember to import from pymodbus.payload import BinaryPayloadDecoder at top and add necessary exception handlers in your final code.
Reference document: https://pymodbus.readthedocs.io/en/latest/source/library/pymodbus.html#pymodbus.payload.BinaryPayloadDecoder

LOAD fails for Method component in USIM card via OTA SMS-DELIVER

I need to load a simple applet to my USIM card. Authentication is OK.
I'm using OTA SMS-DELIVER via SmartCard to install CAP file.
Using these:
https://github.com/simhacks/hello-stk.git
https://github.com/martinpaljak/ant-javacard
I couldnt find the right spec explaining "C482XXYY" in Header.cap, how it should be calculated,
this answer below helped me navigate, but for Method.cap loading - it still fails
https://community.oracle.com/tech/developers/discussion/1753814/globalpaltform-load-command-data-field
I've written this loader:
https://pastebin.com/pSXeDYyS
Every component in CAP file is in separate APDU with LOAD instruction.
First 5 is loaded successfully with DATA=00, SW=9000, however on Method it fails.
As you can see from my script, I've fixed Descriptor size to 0000 in Directory field.
And in Header C482xxyy, where xxyy is calculated properly, which is a sum of
all size fields in Directory, e.g.
016a = 0011+001f+000c+001e+0042+0018+006d+0032+0017+0000+0000
Question: Can't figure out why Method LOAD fails? By checking GP 2.1 spec, it doesnt
help me understand the problem. Concatenated components to < 255 block size also fails,
only separate components work for LOAD.
[+] Install for load
>> 80e602001207d07002ca449001000006ef04c60201850000c0000000
<< 009000
[+] LOAD - Header
>> 80e8000018c482016a010011decaffed010204000107d07002ca44900100c0000000
<< 009000
[+] LOAD - Directory
>> 80e800012202001f0011001f000c001e00420018006d003200170000000000040002002202010000c0000000
<< 009000
[+] LOAD - Import
>> 80e800022104001e02000107a0000000620101060210a0000000090003ffffffff891071000200c0000000
<< 009000
[+] LOAD - Applet
>> 80e800030f03000c0108d07002ca44900101002000c0000000
<< 009000
[+] LOAD - Class
>> 80e800041b06001843800301ff0007020000002f00398002008101010881000000c0000000
<< 009000
[!!!!] LOAD - Method (FAILED)
>> 80e800057007006d000911188c00048d00012c18197b0002037b00029210240303038b000388007a02318f00053d8c00062e1b8b00077a0120188b000860037a7a02228d00092d1d10076b101a8b000a321fae006b06188c000b7a06118d000c2c1903077b000d037b000d928b000e198b000f3b7a00c0000000
<< 9000 (should be 009000)
[-] LOAD - StaticField (FAILED due to last failed LOAD)
>> 80e80006350800.....
<< 6A86 (because prev. p2=05 is not loaded)
Applet source code:
package com.github.mrlnc.HelloSTK2;
import javacard.framework.*;
import sim.toolkit.*;
/*
Originally from: https://git.osmocom.org/sim/hello-stk/tree/hello-stk/src/org/toorcamp/HelloSTK/HelloSTK.java
*/
public class HelloSTK2 extends Applet implements ToolkitInterface, ToolkitConstants {
// DON'T DECLARE USELESS INSTANCE VARIABLES! They get saved to the EEPROM,
// which has a limited number of write cycles.
private byte helloMenuItem;
private HelloSTK2() {
// This is the interface to the STK applet registry (which is separate
// from the JavaCard applet registry!)
ToolkitRegistry reg = ToolkitRegistry.getEntry();
byte[] menuItemText = new byte[] { 'H', 'e', 'l', 'l', 'o'};
// Define the applet Menu Entry
helloMenuItem = reg.initMenuEntry(menuItemText, (short)0, (short)menuItemText.length,
PRO_CMD_SELECT_ITEM, false, (byte)0, (short)0);
}
// This method is called by the card when the applet is installed. You must
// instantiate your applet and register it here.
public static void install(byte[] bArray, short bOffset, byte bLength) {
HelloSTK2 applet = new HelloSTK2();
applet.register();
}
// This processes APDUs sent directly to the applet. For STK applets, this
// interface isn't really used.
public void process(APDU arg0) throws ISOException {
// ignore the applet select command dispached to the process
if (selectingApplet())
return;
}
// This processes STK events.
public void processToolkit(byte event) throws ToolkitException {
EnvelopeHandler envHdlr = EnvelopeHandler.getTheHandler();
if (event == EVENT_MENU_SELECTION) {
byte selectedItemId = envHdlr.getItemIdentifier();
if (selectedItemId == helloMenuItem) {
byte[] welcomeMsg = new byte[] { 'W', 'e', 'l', 'c', 'o', 'm', 'e' };
ProactiveHandler proHdlr = ProactiveHandler.getTheHandler();
proHdlr.initDisplayText((byte)0, DCS_8_BIT_DATA, welcomeMsg, (short)0,
(short)(welcomeMsg.length));
proHdlr.send();
}
}
}
}
UPDATE:
Raw CAP bytes in order (Header, Directory, Import, Applet, Class, Method, StaticField, ConstantPool, RefLocation, Descriptor)
['01000fdecaffed010204000105d07002ca44',
'02001f000f001f000c00280036001800aa000a001200000003000000000000030100', '04002803030107a0000000620101060210a0000000090003ffffffff8910710002000107a0000000620001',
'03000c0108d07002ca449001010039',
'06001843800301ff00070200000048005280020081010108810000', '0700aa000912188c00038d00012c08900b3d031048383d041065383d05106c383d06106c383d07106f382d18191a031a9210240303038b000288007a02318f00043d8c00052e1b8b00067a0120188b000760037a7a06248d00082d1d10076b4e1a8b0009321fae006b441007900b3d031057383d041065383d05106c383d061063383d07106f383d08106d383d100610653828048d000a2805150503071504031504928b000b15058b000c3b7a',
'08000a00000000000000000000', '050036000d02000000068109000381090b0680030001000000060000010380030103800303068108000381080c06810a0003810a1303810a16',
'0900120002372d000c05032c08040507090a330f05',
'0b0003000000']
UPDATE 2:
I'm sending via ENVELOPE commands. KIC1,KID1 encryptions are used. They work with RFM and some RAM commands like GET STATUS etc. Here is the code for INSTALL (for load) command:
def install_for_load(self, caps, exe_aid):
# 11.5.2.3.7 INSTALL Command Parameters, page 174
cap_data = "".join(caps)
apdu = "".join([
"80", # CLS
"e6", # INSTR
"02", # p1 0b000000_1_0 ; for load
"00", # p2
"%02x", # p3 ; Lc
])
# sec_aid = "a000000003000000" # GP211 Security Domain AID
data = "".join([
"%02x" % int(len(exe_aid)/2),
exe_aid,
"00", # security domain aid (same domain)
# "%02x" % int(len(sec_aid)/2), # security domain aid (same domain)
# sec_aid,
"00", # load file data block hash
"%02x", # load params length
])
load_params_tl = "".join([
"ef", # Load Parameters: System Specific Parameters tag
"%02x", # length of load_params
])
load_params_v = "".join([
"c6", # Non-volatile code Minimum Memory requirement. load params (mandatory)
"02", # length
"%04x" % int(len(cap_data)/2), # code size HelloSTK2.cap size.
# "c7", # volatile data minimum memory required (ram) - optional
# "02", # length
# "00ff",
# "c8", # non-volatile data minimum memory required - optional
# "02",
# "00ff"
])
load_params = load_params_tl % int(len(load_params_v)/2) + load_params_v
data = data % int(len(load_params)/2) + load_params
data += "00" # load token
apdu = apdu % int(len(data)/2) + data
apdu += "00c0000000" # C-MAC + Le
return apdu
You can have a look into the GlobalPlatform project loader.
It is LPGL, so directly using it as C code in other non LGPL projects is not possible.
[!!!!] LOAD - Method (FAILED)
80e800057007006d000911188c00048d00012c18197b0002037b00029210240303038b000388007a02318f00053d8c00062e1b8b00077a0120188b000860037a7a02228d00092d1d10076b101a8b000a321fae006b06188c000b7a06118d000c2c1903077b000d037b000d928b000e198b000f3b7a00c0000000
<< 9000 (should be 009000)
I assume that the log is the unwrapped logged before the commands are prepared for SCP80. A response of 9000 in OTA means usually "I received the command, but I don't know what to do with it". Is this 9000 command from the ENVELOPE response on the card? Are you sending the data over an SMPP connection?
Can you try your loading code with a simple HelloWorld Applet without any STK? It could be that your card is not supporting a version you are linking against, e.g. different ETSI releases. Then some method might not be supported and the loading fails.

why the ROM designed from distributed memory block in vivado can't work?

I am trying to use the Distributed Memory Generator presented by vivado to store some data. But the simulation out of the ROM is always 'xxx'.
Here's my IP setting:I named it temp. Memory config: Depth=160, width=12, ROM.
Port config: input options: registered
Here's my testbench:
`timescale 1ns/1ps
module tb();
reg clk;
reg [6:0] a;
wire [11:0] out;
initial
begin
clk <= 0;
a <= 7'b0000000;
end
always #5 clk <= ~clk;
always #20 a <= a + 1;
temp u (.a(a), .clk(clk), .spo(out));
defparam u.inst.C_READ_MIF = "temp.mif";//initial ROM
endmodule
DEPTH = 160;
WIDTH = 12;
ADDRESS_RADIX = BIN;
DATA_RADIX = BIN;
CONTENT
BEGIN
0:100000000010;
1:100000000100;
10:000000000011;
11:100000000001;
100:100000001011;
101:000000000001;
110:000000000001;
111:000000000000;
1000:000000000000;
1001:100000000100;
1010:100000001000;
1011:100000000100;
1100:100000000001;
1101:100000000001;
1110:100000000000;
1111:000000000110;
10000:100000000011;
10001:100000000101;
10010:000000000000;
10011:100000000100;
10100:100000000011;
10101:000000000001;
10110:100000000000;
10111:000000000001;
11000:100000000100;
11001:000000000100;
11010:000000000000;
11011:000000000101;
11100:000000000101;
11101:000000000010;
11110:000000000011;
11111:100000000011;
100000:100000000010;
100001:000000000001;
100010:000000000001;
100011:000000000100;
100100:100000000000;
100101:000000000100;
100110:100000000000;
100111:100000000010;
101000:000000001000;
101001:000000000110;
101010:000000000000;
101011:100000000010;
101100:100000000101;
101101:100000000100;
101110:100000000011;
101111:100000001010;
110000:100000000000;
110001:100000000010;
110010:000000000111;
110011:100000000011;
110100:000000000001;
110101:100000000011;
110110:100000000100;
110111:000000000110;
111000:100000000000;
111001:100000000001;
111010:000000000100;
111011:000000000011;
111100:000000001010;
111101:100000001011;
111110:100000000000;
111111:000000000010;
1000000:000000000000;
1000001:000000000010;
1000010:000000000001;
1000011:000000000100;
1000100:100000000100;
1000101:100000000111;
1000110:000000000100;
1000111:100000000010;
1001000:000000000001;
1001001:100000000000;
1001010:000000000010;
1001011:100000000001;
1001100:100000001010;
1001101:000000000110;
1001110:100000000100;
1001111:000000000100;
1010000:100000000001;
1010001:000000000000;
1010010:000000000000;
1010011:000000000100;
1010100:000000000100;
1010101:100000000001;
1010110:100000000100;
1010111:000000000100;
1011000:100000000110;
1011001:000000000010;
1011010:000000000010;
1011011:000000000100;
1011100:000000001000;
1011101:100000000101;
1011110:100000000000;
1011111:000000000000;
1100000:000000000000;
1100001:100000000110;
1100010:100000000111;
1100011:100000000001;
1100100:100000000000;
1100101:100000000001;
1100110:100000001000;
1100111:000000000010;
1101000:000000000010;
1101001:000000000011;
1101010:100000000010;
1101011:000000000010;
1101100:100000000110;
1101101:100000000000;
1101110:000000000000;
1101111:000000000001;
1110000:000000000011;
1110001:100000000011;
1110010:100000000011;
1110011:100000000101;
1110100:000000001011;
1110101:100000000000;
1110110:100000000001;
1110111:000000000001;
1111000:000000000001;
1111001:100000000000;
1111010:100000000001;
1111011:000000001000;
1111100:000000000000;
1111101:100000000001;
1111110:100000000110;
1111111:100000000100;
10000000:000000000101;
10000001:000000000100;
10000010:000000000101;
10000011:100000000011;
10000100:100000000101;
10000101:000000000001;
10000110:000000000101;
10000111:000000000001;
10001000:000000000001;
10001001:000000000111;
10001010:100000000000;
10001011:100000000100;
10001100:100000001000;
10001101:000000000010;
10001110:100000000010;
10001111:100000000000;
10010000:000000000101;
10010001:000000000011;
10010010:100000000001;
10010011:000000000110;
10010100:000000000110;
10010101:100000000010;
10010110:100000000000;
10010111:000000000000;
10011000:100000000000;
10011001:100000000100;
10011010:000000000100;
10011011:000000000111;
10011100:000000000001;
10011101:100000000010;
10011110:100000000110;
10011111:100000000100;
END
Here's my simulation result
I don't know why out remains '000'. And how should I use the ROM block?
Most likely is that your initialization fails. Check for an error message in your simulation log file like 'Can't open...'.
The reason why I suspect that is because the Xilinx file locations in Vivado are very, very nasty. They are relative to the simulation directory which can be 4 or 5 directories deep inside the Vivado project directory. Not only that, the depth recently changed when I switched to a newer version and I had to adapt every path in every old test-bench! (Thank you Xilinx!!)
This is an example of a simulation where I had to pass a filename in my testbench (tb):
.file_path ("../../../../../test_data/"),
.file_name ("testpattern_00.bin"),
The directory structure I use is:
---+--tb
| |
| +-- test_bench.sv
|
+--test_data
| |
| +-- testpattern_00.bin
|
+--vivado_directory
|
+--vivado_project.xpr

posix_fallocate() failed: Operation not permitted while opening .realm file

I get the below error when i try to open and download .realm file in /tmp directory of serverless framework.
{"errorType":"Runtime.UnhandledPromiseRejection","errorMessage":"Error: posix_fallocate() failed: Operation not permitted" }
Below is the code:
let realm = new Realm({path: '/tmp/custom.realm', schema: [schema1, schema2]});
realm.write(() => {
console.log('completed==');
});
EDIT: this might soon be finally fixed in Realm-Core: see issue 4957.
In case you'll run into this problem elsewhere, here's a workaround.
This caused by AWS Lambda not supporting the fallocate and fallocate64 system calls. Instead of returning the correct error code in this case, which would be EINVAL for not supported on this file system, Amazon has blocked the system call so that it returns EPERM. Realm-Core has code that handles EINVAL return value correctly but will be bewildered by the unexpected EPERM returned from the system call.
The solution is to add a small shared library as a layer to the lambda: compile the following C file on Linux machine or inside lambda-ci Docker image:
#include <errno.h>
#include <fcntl.h>
int posix_fallocate(int __fd, off_t __offset, off_t __len) {
return EINVAL;
}
int posix_fallocate64(int __fd, off_t __offset, off_t __len) {
return EINVAL;
}
Now, compile this to a shared object with something like
gcc -shared fix.c -o fix.so
Then add it to a root of a ZIP file:
zip layer.zip fix.so
Create a new lambda layer from this zip
Add the lambda layer to your lambda function
Finally make the shared object be loaded by configuring the environment value LD_PRELOAD with value /opt/fix.so to your Lambda.
Enjoy.

Python 3.8.0a3 failed to get the Python codec of the filesystem encoding

When I call the embedded python from my c++ app, the application crashes. Something in _PyCodec_Lookup is not working. Debugging seems to indicate the error comes from this line in file codecs.c:
PyInterpreterState *interp = _PyInterpreterState_GET_UNSAFE();
if (interp->codec_search_path == NULL && _PyCodecRegistry_Init())
goto onError;
interp->codec_search_path is NULL and _PyCodecRegistry_Init() returns -1.
This problems is already known; Solutions like removing python27, or setting environment variables PYTHONPATH or PYTHONHOME to either "" or the src path do not work.
I link to cpython version 3.8.0a3 which I've compiled with the included scripts inside the PCBUILD folder, using the same compiler as my applications (MSVC 15 2017).
The OS is windows 8.1 64 bit.
My application links to the produced binary python38.dll / python38.lib successfully but then crashes at runtime, and I have no idea what might cause the trouble - people suggest the environment is polluted, but it must not depend on the system's environment. How would I confidently ship the app to other people's computers? Did I maybe miss some compile flags or defines?
I'm sure you are, but you are doing this after Py_Initialize ?
I include the python3.8 dll but when starting up I take the executable full
path and then add that to the python path (the code below is not tested but
it's roughly what I do)
void py_add_to_path (const char *path)
{
PyObject *py_cur_path, *py_item;
char *new_path;
int wc_len, i;
wchar_t *wc_new_path;
char *item;
new_path = strdup(path);
py_cur_path = PySys_GetObject("path");
for (i = 0; i < PyList_Size(py_cur_path); i++) {
char *tmp = strappend(new_path, PATHSEP);
myfree(new_path);
new_path = tmp;
py_item = PyList_GetItem(py_cur_path, i);
if (!PyUnicode_Check(py_item)) {
continue;
}
item = py_obj_to_str(py_item);
if (!item) {
continue;
}
tmp = strappend(new_path, item);
free(new_path);
new_path = tmp;
free(item);
}
/* Convert to wide chars. */
wc_len = sizeof(wchar_t) * (strlen(new_path) + 1);
wc_new_path = (wchar_t *) malloc(wc_len, "wchar str");
mbstowcs(wc_new_path, new_path, wc_len);
PySys_SetPath(wc_new_path);
}
Seems a bit old now but looks like there is need to add the Lib folder including all the python system files to the search paths of the application.
Take a look at this Python port for UWP
It has an embedded python34app.zip that includes the codec files.

Resources