I just dump my Nfc Mifare classic 1k card and I want to emulate it with my phone (Redmi note 11S, with nfc).
As you can see, only the first sector of this card is write
I find an app name "Ndef tag emulator" for emulate card. I try to emulate with only the UID (D4ECCFCC) but it didn't work.
Have you an idea for writing this on "NDEF syntaxe", oh just khnow a better way to emulate a nfc card?
This information may help you. The Sector 0 is the so called MAD (Mifare Application Directory) which says where the Applications are stored. Within the Sector 0 the first Block (0-15 Bytes) is the Manufactor-Code followed by byte 16 which is an CRC for the MAD and then the Information-Byte which is blocked for further development. Then the Application-Ids (AIDs) starts, where 2 Bytes represent an Application and the Sector to find the Application. By this logic your Data is stored in Sector 1 which is uncommonly not present in your picture.
Related
I am implementing an OTA update system for the STM32G4, and want to use the dual flash banks to make it safe. That is, write the new firmware in the inactive flash bank while the main program is still running from the active bank, and reboot only after checking the integrity of the newly installed firmware.
To do this, I'm setting the BFB2 bit from the option bytes to 1, which, according to AN2606 (section 45.2) and this presentation (page 8), tells the MCU to first attempt booting from flash bank 2 if the stack address located at offset 0x0 of the flash bank 2 is a valid SRAM address. Otherwise the MCU boots from flash bank 1. This fits my use case, as I can write the new firmware to the flash bank 2, except for the stack address which is written only after an integrity check to commit the change.
However, it seems the flash banks addresses aren't swapped when booting from the flash bank 2. According to the programming manual (section 10.2.1), swapping the flash banks addresses is done by setting the FB_MODE bit, which is cleared on reset and does not seem to be set when booting from flash bank 2. Not having the flash banks addresses swapped automatically is problematic because it means the firmware cannot be linked assuming a flash address of 0x08000000.
The workaround I can think of is to integrate a bootloader that checks which bank is in use, set the FB_MODE bit accordingly, then jump to the actual firmware entry point. This bootloader would be flashed in both banks, and not updated during an OTA update.
Is there really no way to swap flash banks addresses automatically when booting from flash bank 2? Or is there another solution which wouldn't involve a bootloader?
Edit: after reading this thread on the ST forums, I am not sure anymore my understanding is correct. If this user is right, then setting BFB2 swaps the banks and their addresses, and setting FB_MODE on top of that would "cancel" the swap.
I finally got this to work after a lot of trial and error. Some of my assumptions were wrong. Here's what the update process looks like:
Check the FB_MODE bit to know which bank the firmware is currently running from.
Perform a mass erase on the other bank (MER2 bit if FB_MODE is 0, MER1 otherwise).
Write the new firmware version at 0x08040000. The inactive bank is always mapped at that address, regardless of FB_MODE.
Set the BFB2 bit in the option bytes if FB_MODE is 0, or clear it otherwise. Do not blindly toggle BFB2, because it does not necessarily reflect which bank is active.
Reload option bytes with the LAUNCH bit, which also resets the MCU.
If the stack top address written at 0x08040000 is valid, the ST bootloader should boot to the new firmware. See step 1.
Some notes:
The firmware is always linked with a virtual address of 0x08000000, regardless of which bank it will be flashed to.
In dual bank mode, the main flash is NOT aliased to 0x0, so the firmware can't be linked to that address.
This does not update the flash option bytes, only the firmware code. I solved this by updating the flash option bytes if necessary when the new firmware boots for the first time.
I am currently working on an I2C communication between an i.MX6 (Android BSP) and a NTAG 5 boost component.
NTA5532 datasheet says :
"According to NFC Forum Type 5 Tag Specification, EEPROM block 0 contains the Capability Container directly followed by the NDEF Message TLV."
In fact, below is the user memory orgnisation of the NTAG 5 boost:
So I used TagInfo NXP's app to read the memory of the NTAG 5 component.
Here is what I get concerning NDEF Capability Container using this app:
How can I decode this block as NXP does in its application?
Following what says this PDF from ST about NDEF management, "The CC manages the information of an NFC Forum T5T", so the structure of this Capability Container is mainly common to all NFC Forum tags.
For more information about how to interpret the CC, see the previous pdf.
i'm using STM32 as my microprocessor along with I2C EEPROM for storage and ESP8266 for Wifi
How can i download an update binary for the bootloader to flash using ESP8266 although the firmware file will be larger than STM32 Ram so i can't load the file from the ESP8266 in one chunk ?
I suppose that you want to update the stm32 firmware.
In this case allow to upload a new binary for the stm32 to the web, store it in the esp8266 file system (it must be bigger than stm32 flash size).
After that, enable flash memory writing, set an small protocol for update stm32 from serial comm from esp8266 the file to stm32 flash.
Remember that all functions that are used to update the stm32 flash must be in RAM.
I'm doing a project for stm32f4 and esp8266 and I will do exactly this.
OPTION 2:
If your program binary size is under 50% of stm32 flash size, then use the above half of the stm32 flash memory to store the new program, after reset, check if there is something there, and if it is then update (this is what i'm doing actually in stm32, very secure method to update since only stm32 cpu is used for update and it is very fast).
I suppose that you have two firmwares on the STM32 flash. First one is boot loader and the second one is your application. Your boot loader gets new firmware over serial interface of the ESP8266; so you can use flow control pins to halt communication until you write the data into flash memory.
I use that combination, stm32 and esp32/esp8266, for now i have not used firmware upgrade from esp (my stm32 supports it but I have not needed it for now).
The easier way is to set a serial protocol between both cpus. I'm using half of the stm32 memory for code and half for updating. What I do actually is using the communication protocolo is copy the file to the upper half of the flash memory. After when i reset the code i check if there is a firmware ready to be updated, then I copy from top half of flash to bottom half.
With this system, you can check if all is ok and the update process with take few ms. After you have this system tested (using for example a PC) you can try to do it from your esp, but it is just as easy as repeat the process.
My tip about the esp8266 is to download the file to a spiffs. If you are not using spiffs, use it, create a drive a little bigger than your memory.. for example if your stm32 firmware binary is around 60kb, and your target cpu is 256, use around 160kb for it.
There is another way, it is download the html file in chunks and then send them to the top half of the cpu, it is not very complex. I would requests chunks with the same size of the block size of your comunnication process (in my case i'm using 256b or 512b, i dont remember at this moment).
Anyways if you have enough spiffs size download the file, update the stm32 cpu, delete the file and send a reboot.
Dont forget to add a crc for data transmision between stm32 and esp8266
Btw you dont need to download it to ram , since update is used rarely and you have limitations like number of times that you can update a flash memory, so, it is not a problem to save it to flash in the esp8266 neither the stm32
Best regards
I am developing an Ionic 2+ application using the NFC plugin.
The issue I run into is how the tag is read differently by a simple USB reader and by the device. The tag IDs are different.
In Ionic I use:
this.nfc.bytesToHexString(event.tag.id)
It is read correctly and I log the result:
From USB reader I get:
On the left is the software for the RFID reader, and on the right are reads with different settings.
What I need is to get the same information for both, the USB reader and the NFC plugin. I don't care about the format.
The IDs that you read are the same except that your USB RFID reader seems to only reads 4 bytes of the 7 byte UID. Since your USB reader doesn't seem to support any other formats, you won't be able to infer the remaining 3 bytes from nowhere. However, you can easily chop off the last three bytes of the UID in your ionic application:
this.nfc.bytesToHexString(event.tag.id.slice(0, 4))
You would then get the same value as for format "8 no. in HEX reverse".
I am researching TinyOS for a school assignment and read that the "core OS is 400 bytes", and another source saying "The footprint of TinyOS is 400 bytes" What exactly does this mean? Is it the actual space it occupies on harddrive?
How big ia a "traditional" OS such as windows?
The answers I have found of what "footprint" actually means is confusing too. Because it seems to mean both actual physical space and memory/disk space.
Just to explain a bit of background, the authors of TinyOS themselves have explained that TinyOS isn't really an operating system:
TinyOS has a component-based programming model, codified by the
nesC language, a dialect of C. TinyOS is not an OS in the traditional
sense; it is a programming framework for embedded systems and set of
components that enable building an application-specific OS into
each application. A typical application is about 15K in size, of which
the base OS is about 400 bytes; the largest application, a
database-like query system, is about 64K bytes.
TinyOS is a software build system designed to allow software engineers to more easily build software for really tiny devices (like this wireless sensor), which do not have a harddrive. Instead, the program is typically stored inside the microcontroller of the device - the device I linked to for example has 48k bytes of flash memory (small embedded devices like these often use flash memory to store their program). 48k of code isn't very much, so it's really important that when you're making software to load onto the device, it takes up as little space as possible.
So, the 'base footprint of 400 bytes' means that, on top of the code that you (the software engineer) write to do whatever your tiny device needs to do, the TinyOS framework (which supports and provides services for your code) only adds an extra 400 bytes (which is really amazing!) to your program code which will actually be loaded onto the device's flash memory. However, this isn't the only overhead - depending on the device, TinyOS may also include various different supporting drivers for whatever chips and components exist on that device.
See figure 6 in this paper for some examples of actual program sizes.
Because of this I have found that building the same application for different devices using TinyOS can yield very different results. For example if I build a really simple program for the MicaZ wireless sensor I get:
compiled NullAppC to build/micaz/main.exe
610 bytes in ROM
4 bytes in RAM
Which means that the total program code, plus the base OS (400 bytes) is 610 bytes (the program will also use 4 bytes of RAM). However if I build the same program for TelosB:
compiled NullAppC to build/telosb/main.exe
1328 bytes in ROM
6 bytes in RAM
1328 bytes! Clearly TelosB requires a lot more additional software, presumably because the components on the TelosB require more complicated additional driver software.