We now have a full buffer 0x01000h each block transfer , 8k goes in as a nice 4k*2
Execution time for the full 8k read of an I2C at 400khz in java:
1433ms
This includes the multiple setups and execution of the commands, again that is without optimizing the java code, so thats not bad compared to pre-block mode.
I have this idea on how to "break" into locked flash, but never got the time to test it There is a bootloader, that can load some application into RAM, and it can also jump to any arbitrary location in memory. I would say, that small program that would read each byte of flash, and send it over uart would work
This was an exploit tried in the 80's , many modern embedded chips now specifically prevent you from doing this, another trick is to load a program into the stack space as JSR's then force execution by wrapping the stack so that the next execution address is the stack.
If you are into dentistry and have to do difficult extractions consider these as a good starting point
Skorobogatov, S.P. (2005) Semi-invasive attacks – A new approach to hardware security analysis.
and
Skorobogatov, Sergei P. & Anderson, Ross J. (2002) Optical Fault Induction Attacks. Lecture Notes in Computer Science, Cryptographic Hardware and Embedded Systems, CHES 2002, http://www.springerlink.com.ezproxy.liv ... 1-JUN-2008
There are some good research works written by Skorobogatov
In China there are places in GuangZhou that will 'decap' a chip for you and re-bond to allow the content to be read out.
Hi, Tracked it down it is ONLY an issue if the transfer is the size of the buffer 4096 (0x1000h)
I think it is here:
Quote
if(fw>=TERMINAL_BUFFER||fr>=TERMINAL_BUFFER){
(for 0x1000h this would fail , since it matches the size of the buffer, but it is actually 0x0fff, with 0 offset)
This should be : if(fw>TERMINAL_BUFFER||fr>TERMINAL_BUFFER){
currently it is failing at the size transfer , because the check does not assume that it is '0' offset since a buffer IS 4096 bytes (0 to 4095), The only way to instruct it to use that size is to issue the following:
out.write(C_I2CWRITEREADCMD);
// set the number of bytes to WRITE out.write(0x00); out.write(0x01);
// set the number of bytes to READ 0=1 !! out.write(0x10); //read size high <-------- out.write(0x00); // read size low <-------- out.write(0xa1);
Then possibly adjust the loops since they track from "0" to max, since we want to transfer 4096 bytes (0x1000h) ,but actually loop from 0 to 0x0ffff.
I've (re-^3)written my perl code back to doing what you outlined, a byte-by-byte write-then-read, and it generally yields reasonable results. Here's my current loop:
I'm used to dealing with this sort of synchronization as a state machine, which is why i force read a byte after a command. Yep we could be clever and 'stack' 3 commands then force read 3 bytes, possibly saving a few ms , but unless we are operating inside a loop a couple of ms is not going to make a difference.
Once the code is debugged,if i think the code will go public then i will throw a function together to make it 'look nice', but generally i keep such code 'unrolled' for speed, not to mention it makes the protocol easier to follow.
Quote
What's interesting is that when I "blast" all 14 bytes down the pipe I seem to be receiving all of the BP status/ACK/NAK stuff but losing the (presumably interleaved) data bytes. Still, race conditions of all kinds usually do have "unpredictable results".
I think what you are seeing is the fact that you are just missing the data before it is overwritten by a status byte, due to overflow ( some place you have missed getting a status byte , and now you are synced to getting status bytes rather than data.....)
consider: for (loop =0 to n; ndata=in.get(); statusbyte=in.get(); }
This code only works if the USART buffer is completely empty just before you enter into the loop, AND (race condition) that there is not a status byte being delivered to the USART between being empty and the "data=in.get();"
That is to say you 'may' check the buffer is empty just outside the loop, but between that check and the loop there may be a char on its way from a previous command. (you are executing code on the nano/micro second level , but the USART is working on the Mili-second level)
just checking of a buffer full transfer of 4k * 2 we are 2 bytes missing at the end (missed picking it up earlier because they were zeroed out.) Seems that we are 1 byte under for each buffer full. its not the script code, because the data is correctly aligned at first boundary.
can we read exactly a buffer full (page multiple) of 4k or is it better to read 4*2k pages instead of 2*4k pages?
Hi Rsdio, I would not put too much store in what Wikipedia says it is not a peer reviewed source, I have seen people do really stupid things, just because they have a piece of paper for some source. There are two main issues: 1. direct "burning" as in 'hay look mom i pointed the laser pointer into my eye and now theres a hole in the back of my head' 2. "Photochemical" , as in 'there is not much research in this area , between semiconductor lasers and eye damage'
Ultimately it depends on the personal choice of how much a person values their eyesight, I could happily be deaf ,but if i went blind ,I would 'end it', that is to say I value my sight far too much.
well if it kills a cellular organism, that should already be a warning that something is going on...........
O.K .... tested it and data looks fine it checks out fine against a copy using the old system to extract it:
read of I2C Before: 8k eprom =131058 ms
After new bulk code: 8k eprom =1456ms
Now we are motoring............
I guess now we are down to to the Java USART bottle neck, but even without optimizing the java , cannot really complain at 2 seconds to read 8k of i2c data.
yep sorry bout the messy description, messy brain syndrome, the initial operating instructions had me confused.
However i still consider there is an error with the way the system responds (yes i do understand what you are saying about you "async" system , but not all scripting can do this, and some are just not fast enough to grab the error before it hits the fan even those supporting Async coms.):
You are relying on the fact that an "async" error needs to kicks off faster than the script can send data, or indeed even start sending data. if the "error" interrupt is delayed then potentially you are feeding data to a bus pirate that will be interpreted as commands.
It is a classic race condition, you have two processes competing against each other, relying on the fact that one can issue an error before the other gets to deeply started, it really is a recipe for disaster.
To be honest I can code round it by making sure the command NEVER issues an error, by range checking the buffer.
Anyway now i have the "byte stream" example let me retest....
Hi, yes you are correct , but what is a 'coherent' source? Take a laser , shine it in a mirror and look into the mirror, Yes I know it is an 'exaggeration' but it will give you a faster result than the laser being reflected from another surface.
I've been looking for my papers on 'Blue' light and free radical damage to optical systems , but its been 3 years all I can find is this:
Okuno, Tsutomu (2008) Hazards of solar blue light.
It relates to 'solar' radiation but the interesting conclusions were the fact that certain frequencies "oxidise" the chemical structure of the eye releasing 'free radicals" more so than other frequencies.
Several years ago we were manufacturing LED lighting, and we ran into a number of 'issues' related to the workers on a Q.A Production line, so we did some research into it, and we were rather surprised by the findings and the more we dug the more 'interesting' it became.
Other issue relate to exactly what power is classed as "high", initially LED lighting was not covered by Safety requirement for emissions, but mid 2000, the British Standard institute and Europe suddenly started to introduce an emissions standard for LED lighting.(which annoyingly I have misplaced)
The real issue is that there have not been any realistic long term studies into more recent semiconductor LED's and laser chips.
Really this thread needs a very significant safety warning, lasers are NOT toys they are a danger to yourself and the people around you, and unless you are prepared to pay several hundred $ for safety equipment, your risking your long term vision.
If you can "see" the beam /dot you are already in danger of going blind.....*. Then there is the issue of lasers that are out of your "visible" spectrum, they will STILL damage your retina, this also includes the new LED diodes especially BLUE. Read the research, guarantee you will not be looking directly at modern LED's again.
*it always amazes me that people think that once laser light has bounced, it is somehow magically different. When you see a laser beam/spot, exactly what do you think you are looking at? the lazed photons are STILL entering your retina otherwise you could not see them, just the damage takes longer.
Just hold off on the I2C bulk read/write , I'm unable to get it to work, there is possibly one potential issue on error reporting, that could cause some real problems.
But I can confirm the existing binary mode is fine. One issue i can see with your code, is that you are not getting the status from the BP after each command sent, If you don't do this, then when you come to read the buffer you will get the backlogged status commands.
for example in java:
out.write(C_CHIPACCESSREG); // TODO chip address (reg) hardcoded only works with 1 chip in.read(); // read reply out.write(0x00); // mem_adddr (hi byte) in.read(); // read reply out.write(0x00); // mem_addr (low byte) in.read(); // read reply
you can actually do: out.write(C_CHIPACCESSREG); // TODO chip address (reg) hardcoded only works with 1 chip out.write(0x00); // mem_adddr (hi byte) out.write(0x00); // mem_adddr (hi byte) in.read(); // read reply in.read(); // read reply in.read(); // read reply
but if the buffer overflows you end-up going out of step between your script and the BP......, which then means you may end up missing the first few bytes of the data you want. The real speed issue is not during setup, but during data transfer, and even with the fastest script your bottle neck is still the USART
The good thing is that the "bulk mode" will slot right in to a script coded the old way requiring only a couple of minor changes.
//get the number of reads to do while(U1STAbits.URXDA == 0);//wait for a byte fr=U1RXREG; //get byte fr=fr<<8; while(U1STAbits.URXDA == 0);//wait for a byte fr|=U1RXREG; //get byte
//check length and report error if(fw>=TERMINAL_BUFFER||fr>=TERMINAL_BUFFER){ I2C_write_read_error: //use this for the read error too UART1TX(0); break; } We only return a code if there is an error? , which means we don't know if we should get a byte until one is sent. (requires polling loop+timeout) it may be better if it returns either 0x01 for good or 0x00 for bad, that way the state is very clear there will always be some sort of reply before sending data/rcving data, we can just wait. Otherwise there is a need to wait an indeterminate amount of time.
The instructions are not clear for the following points:
2&3 the number should be 4095 not 4096, if i send a request for 0x1000h it errors (returns 0x0), but for 0x0fff it returns (0x01) (which shows that part of the code works!!)
4. I assume if it is good then it returns 0x01 (which it does)
All working up to step 4 after step 4 cannot get it to work, just returns 0xFF (old single byte get code still works)
5. if I want to write 0 bytes , do I still send a ACK? , also after i send an ACK will the BP return a 0x01, to to keep the number of bytes received correct for pass/fail cases? 6. do you mean the BP will send two bytes saying how many it has written/read?
I seem to be OK up to stage 4, after that the BP just returns 0xff
9. do you mean i send "C_I2CSTOPBIT" (0x03) 10. if there has been an internal error does the BP return (0X00)?
There is a bootloader, that can load some application into RAM, and it can also jump to any arbitrary location in memory. I would say, that small program that would read each byte of flash, and send it over uart would work