For SPI read, send CMD27, get back command response followed by either data token and data or error token.
Data token is 1 1 1 1 1 1 1 0
Error token is 0 0 0 X X X X X
The problem is as far as I can tell, idle reads as a stream of 1 bits so if I lay the mask like this on the error token I get a valid data token:
start error token here
1 1 1 1 1 1 1 1 1 1 0 0 0 X X X X X X 1 1 1 1
start data token here
If the first data byte read starts with two zero bits (highly probable), this is ambiguous with error token. Looking for end of stream doesn't work as this yields infinite 1 bits. (I anticipate long streams of 1 bits in legitimate reads).
It gets worse considering CMD28 reading across a bad sector (I need long range CMD28 to make my performance requirements). Looking for end of stream swallows the next data start packet.
I do in fact have code (about 70 lines) that can successfully initialize the SD card over this interface and read its configuration registers. I can easily send the read command just fine. But I don't know how to write the code to tell if the response back is success for error.
(Sorry, no code to show. You really wanna see nothing but an ASM loop pulling bits out of a pin?)
After issuing the read block command (CMD17) or read multiple block (CMD18) command, the card will output all 1s until it returns R1 (please correct me if I am wrong).
After returning R1 the card will signal all 1s (reading the spec I get the impression that BUSY is only allowed after a data transfer, unless the response type for that command is R1b in table 7-3).
The first byte which is not all 1s after R1 will be either the data token (0xFE) or it will be the error token (0x0X where X is from 1 to F).
Related
I am trying to convert a benchmark to homomorphic domain, and I'm using Palisade library for that due to its support of multiple schemes like BFV, BGV, CKKS.
I am currently using BFV scheme.
There is a line in the code-
y = x >> 6.
This line in my encrypted domain should look something like this, given Enc(x)-
Enc(y) = Enc(x) >> 6.
I see that division is not supported in Palisade, and think this is also the case with Microsoft SEAL library.
Can someone please guide how to go about this operation in Palisade?
I tried this (but this assumes that bits of x are known, which is not the case as we only know Enc(x))-
If the breakup of the input integer into binary bits is known -
Say we are given integer x=233 and its binary representation as 'vector<int64_t> v= {1 1 1 0 1 0 0 1 }'. We can encrypt this vector into HE domain and get ciphertext1.
Then, say we want to do- x>>6. For this, we can do-
Plaintext plaintext1;
cryptoContext->Decrypt(keyPair.secretKey, ciphertext1, &plaintext1);
plaintext1->SetLength(v.size()-6);
vector<int64_t> v_final=plaintext1->GetPackedValue(); // gives {1 1}
I have built an android app that will send a string of values (using getbyte()_) across a serial connection. I would like each of these values to be stored in a seperate variable/
For example:
a list of numbers like this:
10004056700003
are sent across the connection.
there are a bunch of variables on the arduino side:
A,B,C,D.... etc
i would like to be able to do this:
A = 1
B = 0
C = 0
D = 0
E = 4
F= 0
.... and so on. i will then use these variables to run a certain sequence of functions on the arduino. In this sense the android application is just to control the arduino.
Thanks for the help! :D
Serial communication usually happens byte-wise.
So if you want to transfer a sequence of numbers (>255) the easiest way is to send each digit as a byte.
On the receiving end you basically have two options.
a) you read each byte and do something with it befor reading the next byte.
b) you read the bytes into a buffer array and do something with it later.
If you want to minimize the number of bytes transferred you of course can split the number value into several bytes instead of transferring each digit.
Try sending the data as String, and then you can access each character of the String using the method: StringVariableName.charAt(pos);
With this approach, your code will be more readable.
Check out charAt function here.
I have a board with quite a few flash chips, some of them are showing intermittent failures. Standard memory tests are not showing any specific problem addresses, other than certain chips are failing intermittently under mechanical and thermal stress.
Suspecting the actual connections and not the flash cells themselves, I'm looking for a way to test the parallel bus for address or data pin errors.
There are some memory tests but they apply better to RAM rather than flash memory (http://www.ganssle.com/testingram.htm). Specifically, the parallel flash has a sequence of bus writes to write to each value; a write/verify failure could easily be the write operation which could be any pin on the bus.
Ideas welcome...
The typical memory tests are there to do that. I prefer a pseudo randomizer (deterministic using an lfsr) to the 0xAA, 0x55, 0xFF, 0x00 tests. This allows for an address bus test as well as data bus test in two passes (repeat inverted). I say typical in the sense of wiggle the data bits and address bits both states each and vary the states of signals and their neighbors. The pounding on a ram to create thermal or other stresses, well you cant write very fast to a flash so you cant really do fast write/read cycles.
Flash creates another problem and that is writing then reading back isnt that interesting, you want to write the read back later, hours, days, weeks to determine if the part is actually holding data.
When you say thermal or stress do you mean only during the time it is above X degrees it fails, or do you mean that due to thermal stress it is broken all the time after the event. Likewise with mechanical, while vibrating or under mechanical stress the part fails, but when relieved of that stress it is okay, or the mechanical stress has done permanent damage that can be detected under stress or not.
Now although you cant do fast write/read cycles, you can punish a flash by reading heavily. I have seen read-disturb problems by constant reading of one block or location. Not necessarily something you have time to do for every location, but you might fill the ram with a pseudo random pattern and concentrate on one location for a while, (minutes, tens of minutes), if you have a part that you know is bad see if this accelerates the detection of the problem and if any location will work or only certain ones. then another thing is to read all the locations repetitively for hours/days or leave it sit for hours/days/weeks and then do a read pass without an erase or write and see if it has lost anything.
unfortunately as you probably know each new failure case takes its own research project and development of a new test.
First step to test a memory is data bus test0 0 0 0 0 0 0 • In this test, data bus wiring is properly tested to0 0 0 0 0 0 0 confirm that the value placed on data bus by processor0 0 0 0 0 0 0 is correctly received by memory device at the other end0 0 0 0 0 0 00 0 0 0 0 0 0 • An obvious way to test is to write all possible0 0 0 0 0 0 0 data values and verify 0 0 0 0 0 0 0 • Each bit can be tested independently• To perform walking 1s test, write the first data value given in the table, verify by reading it back, write the second value, verify and so on. • When you reach the end of the table, the test is complete
In the linked article Jack Ganssle says: "Critical to this [test], and every other RAM test algorithm, is that you write the pattern to all of RAM before doing the read test."
Since reading should be isolated from writing, testing the flash is easier. Perform the writing portion of the tests while the system is not under stress. Then perform the reading portion with the system under stress. By recording the address, expected value, and actual value in enough error cases, you should be able to determine the source of the errors.
If the system never fails when doing the above, you can then perform the whole tests while under stress. Any errors that appear are most likely write errors.
I've decided to design a memory pattern that I think I can deduce both data and address errors from. The concept is to use values significantly different as key indicators of possible read errors. The concept is also to detect a failure on one pin at a time.
The test will read alternately from only bottom and top addresses (0x000000 and 0x3FFFFF - my chip has 22 address lines). In those locations I will put 0xFF and 0x00 respectively (byte wide). The idea is to flip all address and data lines and see what happens. (All other values in the flash have at least 3 bits different from 0x00 and 0xFF)
There are 44 addresses that a single pin failure could send me to in error. In each address put one of 22 values to represent which of the 22 address pin was flipped. Each are 2 bits different from each other, and 3 bits different from 00 and FF. (I tried for 3 bits different from each other but 8 bits could only get 14 values)
07,0B,0D,0E,16,1A,1C,1F,25,29,2C,
2F,34,38,3D,3E,43,49,4A,4F,52,58
The remaining addresses I put a nice pattern of six values 33,55,66,99,AA,CC. (3 bits different from all other values) value(address) = nicePattern[ sum of bits set in address % 6];
I tested this and have statistically collected 100s of intermittent failure incidents synchronized to the mechanical stress.
single bit errors detectable
double bit errors deducible (Explainable by a combination of frequent single bit errors)
3 or more bit errors (generally inconclusive)
Even though some of the chips had 3 failing pins, 70% of the incidents were single bit (they usually didn't fail at the same time)
The testing group is now using this to identify which specific connections are failing.
From Section 4.1 of Programming in Lua.
In a multiple assignment, Lua first evaluates all values and only then
executes the assignments. Therefore, we can use a multiple assignment
to swap two values, as in
x, y = y, x -- swap x' fory'
How does the assignment work actually?
How multiple assignment gets implemented depends on what implementation of Lua you are using. The implementation is free to do things anyway it likes as long as it preserves the semantics. That is, no matter how things get implemented, you should get the same result as if you had saved all the values in the RHS before assigning them to the LHS, as the Lua book explains.
If you are still curious about the actual implementation, one thing you can do is see what is the bytecode that gets produced for a certain program. For example, taking the following program
local x,y = 10, 11
x,y = y,x
and passing it to the bytecode compiler (luac -l) for Lua 5.2 gives
main <lop.lua:0,0> (6 instructions at 0x9b36b50)
0+ params, 3 slots, 1 upvalue, 2 locals, 2 constants, 0 functions
1 [1] LOADK 0 -1 ; 10
2 [1] LOADK 1 -2 ; 11
3 [2] MOVE 2 1
4 [2] MOVE 1 0
5 [2] MOVE 0 2
6 [2] RETURN 0 1
The MOVE opcode assigns the value in the right register to the left register (see lopcodes.h in the Lua source for more details). Apparently, what is going on is that registers 0 and 1 are being used for x and y and slot 2 is being used as a temporary extra slot. x and y get initialized with constants in the first two opcodes and in the next three 3 opcodes a swap is performed using the "temporary" second slot, kind of like you would do by hand:
tmp = y -- MOVE 2 1
y = x -- MOVE 1 0
x = tmp -- MOVE 0 2
Given how Lua used a different approach when doing a swapping assignment and a static initialization, I wouldn't be surprised if you got different results for different kinds of multiple assignments (setting table fields is probably going to look very different, specially since then the order should matter due to metamethods...). We would need to find the part in the source where the bytecode gets emitted to be 100% sure though. And as I mentioned before, all of this might vary between Lua versions and implementations, specially if you look at LuaJIT vs PUC Lua.
I'm trying to implement the Go back N protocol on two separate client and server applications. Say my sequence numbers must fit 3 bits, so 2^3 = 8 max numbers, and 2^3 - 1 = 7 window size.
I initially send my whole window. The first two packets (0 and 1) are received correctly. Packet 2 is dropped. When the Receiver gets packets 3 through 6, it was expecting 2, so it must nack the packet it got saying it wants 2.
Sender Receiver
0 0
1 1
2 (packet dropped)
3 nack2
4 nack2
5 nack2
6 nack2
When the Sender receives the first nack2, it understands that 0 and 1 have been received (through piggybacking) and move its window forward, but it must also resend its window starting at sequence number 2 (so 2-3-4-5-6- and possibly 7-0). By the time the Sender receives the second nack2, it has already sent those packets. Because of the protocol, the Sender will again resend his entire window, including 2. Now the Receiver will possibly receive 2 (and the others), but in the second nack2 batch it will re-receive 2, which is out of sequence, will have to nack its expected packet, and so on. Am I correct in all these assumptions?
If I am, it seems to me that Go Back N is sending a lot more packets than Stop and Wait, especially the more you increase its window size. What am I not getting?
The solution I found to this problem was to simply use more bits to represent the sequence number and therefore have a larger MAX. If your MAX is 2 * Window size, then a delayed 2 cannot be misinterpreted as a proper ACK.