MKE02Z SPI Communication TxBuffer not copied - arm

I am Trying to Implement an SPI communication between the Freescale FRDM_KE02Z40M(MKE02 MCU) Evaluation-Board and the ESP32S3.
The ESP32S3 sends 32byte of data. The FRDM_KE02Z40M should send 32 byte back.
However, while the data send by the ESP is recieved correctly, only the first byte of the data the FRDM_KE02Z40M should send is actually transmitted. After that, the ESP32 only recieves his own transmission repeated back to him.
Daten send from ESP32S3:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
data MKE02Z (FRDM-Board) should send:
BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB
BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB
Daten recieved by ESP32S3:
BB 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E
0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E
Data recieved by the MKE02Z:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
The relevant code of the ISR looks like this:
void spi_slave_irq(spi_handle_t *handle){
uint8_t flags = spi_getStatusRegister();
//Check wether the Transmit Buffer empty flag is set and if so, write the next 8 bit to SPI0_D
if(((flags & 0xFFU) & SPI_S_SPTEF_MASK) != 0)
{
spi_write_shiftregister(*(handle->txData));
handle->txData++;
handle->txindex++;
}
//Check wether the Recieve Buffer full flag is set and if so, read the next 8 bit from SPI0_D
if(((flags & 0xFFU) & SPI_S_SPRF_MASK) != 0)
{
*(handle->rxData) = spi_read_shiftregister();
handle->rxData++;
handle->rxindex++;
}
...
The RxBuffer Full Flag is reliantly set during transmission and the shiftregister copied to the rxbuffer every 8 bit.
However, the TxEmpty Statusflag is never set during a Transmission but only BEFORE and AFTER it. When the MCU is reset, the txbuffer empty flag is set, the interrupt called, the buffer filled and directly copied to the shiftregister. The TxBuffer Flag is then raised again, interrupt called again and txbuffer filled with the second byte. The System then idles until communication is initiated by the master. During Transmission (when SS is Low), the TxBufferFull Flag is never raised again. This leads me to the assumption, that the TxBuffer is not copied to the shift register of the SPI Module during the Transmission.
This makes sense, as if the TxBuffer is not copied to the shift register the data recieved from the ESP32 would stay on the shift register and be repeated back to it the next 8 shifts.
I provided a Sketch of how the SPI Module works according to data sheet and reference manual:
SPI_MODULE_Sketch
Is such a Problem known? Could it be that the SPI-Module on this MCU is faulty? (I tried it with 2 different Boards. I used 2 Drivers provided by NXP (Freescale Driver and CMSIS Driver) and wrote my own directly following the Reference Manual. NXP is not reacting to contact requests until now.
The error exists exactly the same within the example projects, my version and on both Boards.

Related

How the Number of Expected bytes is calculated in Modbus RTU with Function Code 2

i am trying to find out how the Number of expected bytes is calculated with Function Code 2 in Modbus RTU.
I am querying registers from 0 to 71, but as a response i am getting expected bytes as 9
Below is the Query and response.
query : 33 02 00 00 00 47 3C 2A
resp : 33 02 09 00 08 00 FE FF FF FF FF 03 FA 68
You queried for 71 bits, the response has 9 bytes containing 8 bits per byte, any excess bits are ignored.

h264 inside AVI, MP4 and "Raw" h264 streams. Different format of NAL units (or ffmpeg bug)

TL;DR: I want to read raw h264 streams from AVI/MP4 files, even broken/incomplete.
Almost every document about h264 tells me that it consists of NAL packets. Okay. Almost everywhere told to me that the packet should start with a signature like 00 00 01 or 00 00 00 01. For example, https://stackoverflow.com/a/18638298/8167678, https://stackoverflow.com/a/17625537/8167678
The format of H.264 is that it’s made up of NAL Units, each starting
with a start prefix of three bytes with the values 0x00, 0x00, 0x01
and each unit has a different type depending on the value of the 4th
byte right after these 3 starting bytes. One NAL Unit IS NOT one frame
in the video, each frame is made up of a number of NAL Units.
Okay.
I downloaded random_youtube_video.mp4 and strip out one frame from it:
ffmpeg -ss 10 -i random_youtube_video.mp4 -frames 1 -c copy pic.avi
And got:
Red part - this is part of AVI container, other - actual data.
As you can see, here I have 00 00 24 A9 instead of 00 00 00 01
This AVI file plays perfectly
I do same for mp4 container:
As you can see, here exact same bytes.
This MP4 file plays perfectly
I try to strip out raw data:
ffmpeg -i pic.avi -c copy pic.h264
This file can't play in VLC or even ffmpeg, which produced this file, can't parse it:
I downloaded mp4 stream analyzer and got:
MP4Box tells me:
Cannot find H264 start code
Error importing pic.h264: BitStream Not Compliant
It very hard to learn internals of h264, when nothing works.
So, I have questions:
What actual data inside mp4?
What I must read to decode that data (I mean different annex-es)
How to read stream and get decoded image (even with ffmpeg) from this "broken" raw stream?
UPDATE:
It seems bug in ffmpeg:
When I do double conversion:
ffmpeg -ss 10 -i random_youtube_video.mp4 -frames 1 -c copy pic.mp4
ffmpeg pic.mp4 -c copy pic.h264
But when I convert file directly:
ffmpeg -ss 10 -i random_youtube_video.mp4 -frames 1 -c copy pic.h264
I have NALs signatures and one extra NAL unit. Other bytes are same (selected).
This is bug?
UPDATE
Not, this is not bug, U must use option -bsf h264_mp4toannexb to save stream as "Annex B" format (with prefixes)
"I want to read raw h264 streams from AVI files, even broken/incomplete."
"Almost everywhere told to me that the packet should start with a signature like : 00 00 01 or 00 00 00 01"
"...As you can see, here I have 00 00 24 A9 instead of 00 00 00 01"
Your H264 is in AVCC format which means it uses data sizes (instead of data start codes). It is only Annex-B that will have your mentioned signature as start code.
You seek frames, not by looking for start codes, but instead you just do skipping by frame sizes to reach the final correct offset of a (requested) frame...
AVI processing :
Read size (four) bytes (32-bit integer, Little Endian).
Extract the next following bytes up to size amount.
This is your H.264 frame (in AVCC format), decode the bytes to view image.
To convert into Annex-B, try replacing first 4 bytes of H.264 frame bytes with 00 00 00 01.
Consider your shown AVI bytes (see first picture) :
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 4C 49 53 54 BA 24 00 00 6D 6F 76 69 ....LISTº$..movi
30 30 64 63 AD 24 00 00 00 00 24 A9 65 88 84 27 00dc.$....$©eˆ„'
C7 11 FE B3 C7 83 08 00 08 2A 7B 6E 59 B5 71 E1 Ç.þ³Çƒ...*{nYµqá
E3 9C 0E 73 E7 10 50 00 18 E9 25 F7 AA 7D 9C 30 ãœ.sç.P..é%÷ª}œ0
E6 2F 0F 20 00 3A 64 AA CA 5E 4F CA FF AE 20 04 æ/. .:dªÊ^OÊÿ® .
07 81 40 00 48 00 0A 28 71 21 84 48 06 18 90 0C ..#.H..(q!„H....
31 14 57 9E 7A CD 63 A0 E0 9B 96 69 C5 18 AE F2 1.WžzÍc à›–iÅ.®ò
E6 07 02 29 01 20 10 70 A1 0F 8C BC 73 F0 78 FA æ..). .p¡.Œ¼sðxú
9E 1D E1 C2 BF 8C 62 CE CE AC 14 5A A4 E1 45 44 ž.á¿ŒbÎά.Z¤áED
38 38 85 DB 12 57 3E F6 E0 FB AE 03 04 21 62 8D 88…Û.W>öàû®..!b.
F6 F1 1E 37 1C A2 FF 75 1C F1 02 66 0C 92 07 06 öñ.7.¢ÿu.ñ.f.’..
15 7C 90 15 6F 7D FC BD 13 1E 2B 0C 14 3C 0C 00 .|..o}ü½..+..<..
B0 EA 6F 53 B4 98 D7 80 7A 68 3E 34 69 20 D2 FA °êoS´˜×€zh>4i Òú
F0 91 FC 75 C6 00 01 18 C0 00 3B 9A C5 E2 7D BF ð‘üuÆ...À.;šÅâ}¿
Some explanation :
Ignore leading multiple 00 bytes.
4C 49 53 54 D6 3C 00 00 6D 6F 76 69 including 30 30 64 63 = AVI "List" header.
AD 24 00 00 == decimal 9389 is AVI's own size of H264 item (must read in Little Endian).
Notice that the AVI bytes include...
- a note of item's total size (AD 24 00 00... or reverse for Little Endian : 00 00 24 AD)
- followed by item data (00 00 24 A9 65 88 84 27 ... etc ... C5 E2 7D BF).
This size includes both the 4 bytes of the AVI's"size" entry + expected bytes length of the item's own bytes. Can be written simply as:
AVI_Item_Size = ( 4 + item_H264_Frame.length );
H.264 video frame bytes in AVI :
Next follows the item data, which is the H.264 video frame. By sheer coincidence of formats/bytes layout, it too holds a 4-byte entry for data's size (since your H264 is in AVCC format, if it was Annex-B then you would be seeing start code bytes here instead of size bytes).
Unlike AVI bytes, these H264 size bytes are written in Big Endian format.
00 00 24 A9 = size of bytes for this video frame (instead of start code : 00 00 00 01).
65 88 84 27 C7 11 FE B3 C7 = H.264 keyframe (always begins X5, where the X value is based on other settings).
Remember after four size bytes (or even start codes) if followed by...
byte X5 = keyframe (IDR), example byte 65.
byte X1 = P or B frame, example byte 41.
byte X6 = SEI (Supplemental Enhancement Information).
byte X7 = SPS (Sequence Parameter Set).
byte X8 = PPS (Picture Parameter Set).
bytes 00 00 00 X9 = Access unit delimiter.
You can find the H.264 if you search for exact same bytes within AVI file. See third picture, these are your H.264 bytes (they are cut & pasted into the AVI container).
Sometimes a frame is sliced into different NAL units. So if you extract a key frame and it only shows 1/2 or 1/3 instead of full image, just grab next one or two NAL and re-try the decode.

searching Tags (TLV) with C function

I' m working on Mastercard Paypass transactions, I Have sent a READ RECORD command and got the result:
70 81 AB 57 11 54 13 33 00 89 60 10 83 D2 51 22
20 01 23 40 91 72 5A 08 54 13 33 00 89 60 10 83
5F 24 03 25 12 31 5F 25 03 04 01 01 5F 28 02 00
56 5F 34 01 01 8C 21 9F 02 06 9F 03 06 9F 1A 02
95 05 5F 2A 02 9A 03 9C 01 9F 37 04 9F 35 01 9F
45 02 9F 4C 08 9F 34 03 8D 0C 91 0A 8A 02 95 05
9F 37 04 9F 4C 08 8E 0E 00 00 00 00 00 00 00 00
42 03 5E 03 1F 03 9F 07 02 FF 00 9F 08 02 00 02
9F 0D 05 00 00 00 00 00 9F 0E 05 00 08 00 60 00
9F 0F 05 00 00 00 00 00 9F 42 02 09 78 9F 4A 01
82 9F 14 01 00 9F 23 01 00 9F 13 02 00 00
This response contains TLV data objects (without spaces). I have converted the response as described in the following:
// Read Record 1 with SFI2
//---------------------------------SEND READ RECORD-------------------
inCtlsSendVAPDU(0x2C,0x03,(unsigned char *)"\x00\xB2\x01\x14\x00",5);
clrscr();
inRet = inCTLSRecv2(Response, 269);
LOG_HEX_PRINTF("Essai EMV4 Read record 1 EMV Paypass:",Response,inRet);
if(Response[14]==0x70)
{
sprintf(Response_PPSE,"%02X%02X",Response[12],Response[13]);//To retrieve length of received data
t1=hexToInt(Response_PPSE);// Convert length to integer
t11=t1-2;
i=14;
k=0;
//--------------------------- Converting data to be used later---------
while(i<t11+14)// 14 to escape the header+ command+ status+ length
{
sprintf(READ1+(2*k),"%02X",Response[i]);
i++;
k++;
}
Now I should check if this Response contains the Mandatory Tags:
5A - Application Primary Account Number (PAN)
5F24 - Application Expiration Date
8C - Card Risk Management Data Object List 1 (CDOL1)
8D - Card Risk Management Data Object List 2 (CDOL2)
So I tried the following to check for the 5A tag (Application Primary Account Number (PAN)):
i=0;
t11=2*t11;
while(i<=t11)
{
strncpy(Response_PPSE,READ1+i,2);
if(strncmp(Response_PPSE,"\x05\x0A")==0)
{
write_at("true",4,1,1);// Just to test on the terminal display
goto end;
}
else
i=i+2;
}
goto end;
I don't know why nothing is displayed on the terminal, The if block is not executed!
I tried to print the 5A tag manually by:
strncpy(Response_PPSE,READ1+44,2);
write_at(Response_PPSE,strlen(Response_PPSE),1,1);
And it display the right value!!
Can someone helps to resolve this issue?
You don't find that tag because you are not searching for the string "5A" but for the string "\x05\x0A" (ENQ character + line feed character). Moreover, I wonder if the above code actually compiles as you did not specify the mandatory length argument to strncmp(). You could try something like
if(strncmp(Response_PPSE,"5A", 2)==0)
instead.
However, you should understand that you are scanning the whole response data for the value 5A. Therefore, finding this value could also mean that it was part of some other TLV tag's data field, length field or even part of a multi-byte tag field. It would therefore make sense to implement (or use an existing) TLV parser for the BER (Basic Encoding Rules) format.
It's not a good approach to search a specific byte in a raw byte-stream data using strings functions at first place.
The generic TLV parser is a very easy algorithm and you will do it in 30 minutes or so.
In general a pseudo-code for TLV parser that look for a specific Tag would be something like this:
index = 0
while (byte[i] != 0x5A or EOF)
{
length = DecodeLength(byte[i+1])
i += length + 2 // + 1 for L (length) byte itself, it might be encoded with
// 2 bytes so the function DecodeLength can return the number
// of bytes lenght has been encoded
// +1 for T (tag) byte
}
if(EOF) return tag_not_found
return byte[i + 2], length // pointer to data for Tag '5A'and length of data

Reading a NFC Mifare card with NXP Reader Library

I'm trying to read the content of a Mifare Ultralight card using the NFC Reader Library.
I'm totally new with NFC and I'm using this github repository to start.
The code in this repo allows to detect which type of card is detected (Mifare, Mifare ultralight ...) and read the UID of the card. I added this code in order to read the content of a Mifare ultralight card:
uint8_t bBufferReader[96];
memset(bBufferReader, '\0', 0x60);
PH_CHECK_SUCCESS_FCT(status, phalMful_Read(&alMful, 4, bBufferReader));
int i;
for(i = 0; i < 96; i++){
printf("%02X", bBufferReader[i]);
}
I have a card that contains the text "Hello world" and when I read it, the piece of code above print the following bytes:
0103A010440312D1010E5402667248650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
So I'm reading some stuff out of my card, however there is no traces of a "Hello world"
text.
Probably missing something (might be a big something or, hopefully, a little something). Any help would be great !
Edit
So I made some good progress. Mifare ultralight contains 16 pages of 4 bytes, 0 - 3 are for internal usage (serial number, lock etc ...) and 4 - 15 are for user data. I can now read the content of my cards, however, just a few question remains:
I'm reading a card that contains an URL, www.google.com, here is what I got:
03 0F D1 01 -> Page 1, 4 bytes of non text data, not sure what it is
0B 55 01 67 -> Page 2, 3 bytes of non text data, then 1 bytes for the "g"
6F 6F 67 6C -> Page 3, 4 bytes for "oogl"
65 2E 63 6F -> Page 4, 4 bytes for "e.co"
6D FE 00 00 -> Page 6, 1 byte for "m", 1 byte for I don't know
00 00 00 00 -> Other pages are just empty
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
So I have got 7 bytes of data + my url, "google.com" + 1 byte FE
I can't find what are these 7 prefix bytes + this 1 trailing byte...
Edit again
Ok got it, it's the NDEF message format.
Yes it is NDEF format!
03 NDEF Message
0F length
Record 1
D1 - MB, ME, SR, TNF=”NFC Forum well-known type”
01 Type length
0B Payload length
55 Type - “U”(Abbrivation for URL)
67 6F 6F 67 6C 65 2E 63 6F 6D (google.com)
Record 2
FE Terminator NDEF

DNS Query Structure

When I am sending a DNS query to the DNS it returns the header with the format bit set.
Indicating there is a problem with the format, but I am failing to see what it is. Its possible I have misinterpreted the RFC, or misread it but right now I cant seem to work it out.
The DNS structure I am sending looks like this in hex.
Header
00 01 - ID = 1
01 00 - RD = 1
00 01 - QD = 1
00 00 - AN
00 00 - NS
00 00 - NR
Question for www.google.com
03 77 - 3 w
77 77 - w w
06 67 - 6 g
6f 6f - o o
67 6c - g l
65 03 - e 3
63 6f - c o
6d 00 - m 0
00 01 - QTYPE
00 01 - QCLASS
I then flip the bytes for any field that is two bytes, to convert to big endian for the network format. So each row of the header, and then QTYPE and QCLASS ...
Here's what a byte-by-byte hexdump of that query packet should look like (tested and working!):
00000000 00 01 01 00 00 01 00 00 00 00 00 00 03 77 77 77 |.............www|
00000010 06 67 6f 6f 67 6c 65 03 63 6f 6d 00 00 01 00 01 |.google.com.....|
I think your problem is that the third and fourth bytes of the packet (flags and rcode) are two single-byte fields, not one 2-byte field - it looks like you might be treating it as a 16 bit integer and swapping the bytes?
To get these you can use netcat and dig.
# nc –uip 53 > dnsreqdump
# dig www.example.com #localhost
# nc –u 8.8.8.8 53 <dnsreqdump >dnsrespdump
Now you can inspect them in hexedit or your favorite hex editor.
I tend to think that your problem depends on how are you actually "flipping the bits to convert to network format".
Typical C library implementations provide the htonl() function family to do the conversion from host into network order and viceversa.
Of course, without seeing the code, I cannot be sure that this is the problem.

Resources