I want to do mass erase on my msp430f2619 using bsl. I use software jump in my code to invoke bsl. I send 0x80, get 0x90 from BSL(ack). Then i send mass erase command and get 0x90 again. Then i power off my device, then i power on the device, then i send 0x80 and get 0x90, that means there was no mass erase operation.
Read command is not working too. I send password (0xFF 32 times), after that send rx command, then i get few coorect bytes, and then infinite raw of 0xff.
I think i miised something before jump to bsl, please give an example code, or step by step instruction on how to make software jump to bsl and make it work correctly.
If you are sending 0x80 only, then get back 0x90, this confirms you have entered into the BSL since this completes the required synchronization sequence (see section 2.1 of this document). You should not require the "RX password" command since the "Mass erase" command is not protected.
The next sequence after the synchronization is to send the desired command, which should be the "Mass erase". There is a format to each of the BSL commands called the data frame. You want to send the following data frame: eight mandatory bytes (note two dummy bytes), and two checksum bytes. Note the "Mass erase" command does not contain data bytes, but you need to calculate the checksum bytes. Here are the bytes to be sent to perform the mass erase:
80 18 04 04 dd dd 06 A5 CL CH
Where: dd = dummy bytes (any value accepted), CL = Checksum low, CH = Checksum high
After sending this data frame then you should receive the ACK (0x90) byte. Then power off the device.
Related
When sending the FormatPICC command to a MIFARE DESFire EV1 card, I observe the following behavior:
PCD ---> PICC
--------------
0xFC --->
<--- 0x00 or 0x00 + MAC or ERROR CODE
If authenticated with the command 0x0A (legacy (3)DES authentication), the response to the FormatPICC command is only one byte (0x00).
If authenticated with the command 0xAA (AES authentication), the response to the FormatPICC command is the status byte (0x00) plus the MAC.
When I send another command (e.g. GetVersion (0x60)), the response does not contain the MAC regardless of which authentication was used (0x0A or 0xAA).
Why is that difference? Should I still calculate the MAC for such commands (to update crypto state)? Is there some document that explains that?
Your observation seems to be wrong. Once authenticated using either AuthenticateISO (0x1A) with TDES or AuthenticateAES (0xAA), MIFARE DESFire EV1 will return a MAC in response to all commands (except, of course, the authentication commands and SelectApplication, which both reset authentication).
Consequently, a MAC should be returned in response to the GetVersion command. However, note that the GetVersion command is split across 3 frames. The MAC is only appended to the last frame (the one with the status code 0x00):
PCD ---> PICC
--------------
0x60 --->
<--- 0xAF + DATA
0xAF --->
<--- 0xAF + DATA
0xAF --->
<--- 0x00 + DATA + MAC
I am reworking the programmer for the Olimex iCE40HX1K board (targetted towards a STM32F103 ma) where I also would like to implement the "SPI Slave" mode to configure an image directly into RAM without using the serial flash.
Looking at the Lattice "programming and Configuration guide" (page 11), it is noted in table 8 that a EPROM for a ICE40-LP/LX1K must be at least 34112 bytes. (which -I guess- means that the configuration-files can be up to that size).
However, all images I have (sofar) created with the icestorm tools are 32220 octets.
I am a bit puzzled here.
Can somebody explain the difference between these two figures?
Does the HX1K need a configuration-file of 32220 or 34112 bytes?
I don't know how Lattice arrived at this number. A complete HX1K bin file with BRAM initialization but without comment and without multiboot header is 32220 bytes in size. The (optional) multiboot header would add another 160 bytes (32220 + 160 = 32380). The lattice tools usually add about 80 bytes to the comment field (32220 + 80 = 32300). Whatever I do, all numbers I have are more than 1000 short of 34112.
I don't know if there is a maximum length for the comment. Maybe there is and 34112 is the size of a bit stream with a comment of maximum length?
34112 - 32220 = 1892. Maybe someone decided to add 8kB (8192 bytes) just in case, but that person accidentally swapped the first two digits? Idk..
If you don't care about comments or multiboot headers, then iCE40 1K bit-streams have a fixed size, and that size is 32220 bytes.
I'm reading this data sheet for a camera.
Datasheet
I have my Arduino communicating with the camera over SPI and can send it a command to take a picture.
The last step is to send a command to retrieve the data, which I'm stuck on.
On page 4 the command DATA is
FF FF FF 0x0A 0X05 Length Byte 0 Length Byte 1 Length Byte 2'
So in code the command would look like this. But how do I figure out what Length Byte 0, Byte 1 Length Byte 2 are??
uint8_t DataCmd[8] = { 0xff, 0xff, 0xff, 0x0a, 0x05, ?, ?, ?};
On page 6 it says
Image Length = len 0 + Len 1 * 100h + Len 2 * 10000h
What does this mean? And how to I translate it into the three parameters that I need for my command?
As you can read, the DATA command is a command sent BY the camera to you. The flow chart at page 9 shows what it does
When the camera receives "get picture",
is the picture ready? if not send a NAK and return
if it is send an ACK
send the DATA command (with the length)
send the picture data
wait for the host to send an ACK
Page 10 has the steps you have to perform. I'll copy them here for future reference:
Establish communication with the camera
Send command INIT (e.g. FFFFFF0100870107h)
Wait for the ACK (e.g. FFFFFF0E01nn0000h)
Send command SELECT IMAGE QUALITY (e.g. FFFFFF1000000000h)
Wait for the ACK (e.g. FFFFFF0E10nn0000h)
Send command GET PICTURE (e.g. FFFFFF0405000000h)
Wait for the ACK (e.g. FFFFFF0E04nn0000h)
Wait for the DATA (e.g. FFFFFF0AnnL0L1L2h)
Receive Image Data
The DATA packet contains L0, L1 and L2, which contain the data image length. L0 is the low-order byte, so if L0 = 0x45, L1 = 0x23, L2 = 0x01 the total length will be 0x012345 = L0 + L1 * 0x100 + L2 * 0x1000; this means that the image is 0x12345 = 74565 bytes, so you know how many bytes you will receive before actually receiving them
I am implementing USB as a host using OHCI to read the files stored in the Flashdrive. To read I implement the read(10) command in SCSI. The Logical Block address being the sector number. The following is an image of the command I send for read(10) to read LBA 0x0000-
http://i.imgur.com/ky4FHlm.png
I read 512bytes(size of one sector or 1 LBA)and the following is the output that i get for LBA 0x0000-
http://imgur.com/jL6OEjE
The bytes in the above image are not present any where on the pendrive, I checked that using HXD. Now, for testing I filled the pendrive to full capacity. If I read any other LBA, other than 0x0000, then I always get 512 bytes of 0x00.
Could anyone please tell me what the problem could be?
Am I supposed to execute some other command before I do a read(10) so that the USB sends me the right data maybe?
From my understanding I have put DPO, FUA and FUA_NV=0 and also RDPROTECT=2
I am using this port of FreeRTOS and I am loading it onto the Cortex-M3 within an OMAP4430. This works fine using the remote proc framework and I am able to use RPMsg to communicate with it.
Sometimes, however, rproc fails to load the elf and gives the following error:
rproc remoteproc1: bad phdr da 0x0 mem 0x10310
rproc remoteproc1: Failed to load program segments: -22
rproc remoteproc1: rproc_boot() failed -22
This seems to happen when the size of the elf file gets too large: this happens when the size is 377331 bytes but does not happen when I simply remove a bunch of print statements and bring the size down to 342563 bytes.
I have tracked the error message down to this piece of code: http://lxr.free-electrons.com/source/drivers/remoteproc/remoteproc_elf_loader.c?v=3.9#L188. It seems that rproc_da_to_va is unable to find a segment in memory large enough to fit the ELF.
How can I make sure that there is enough memory for the size of my ELF? Can I tell the kernel that I specifically want a certain region preallocated for this kind of thing? Is there some way to ensure that this part of my ELF remains small?
Thanks!
Make sure that the FreeRTOS configuration constants configTEXT_SIZE and configDATA_SIZE agree with the amounts demanded by your linker script. For example, if your linker script contains
MEMORY
{
TEXT (rwx) : ORIGIN = 0x00000000, LENGTH = 1M
DATA (rwx) : ORIGIN = 0x80000000, LENGTH = 1M
}
then you should set configTEXT_SIZE and configDATA_SIZE to 0x100000.