I used nandtest utility to test flash memory. After test, flash memory data was damaged. First flash memory card data was damaged by this command:
nandtest /dev/mtd3
Then, I saw C resources of nandtest from git, and I have found, that this call should work for me:
nandtest -k /dev/mtd3
But, flash memory data was damaged again. This is output of nandtest call:
ECC corrections: 26
ECC failures : 696
Bad blocks : 0
BBT blocks : 0
00100000: reading...
1 bit(s) ECC corrected at 00100000
001a0000: reading...
1 bit(s) ECC corrected at 001a0000
00f40000: reading...
2 bit(s) ECC corrected at 00f40000
01d40000: reading...
1 bit(s) ECC corrected at 01d40000
02300000: reading...
ECC failed at 02300000
02ac0000: reading...
1 bit(s) ECC corrected at 02ac0000
03e60000: reading...
1 bit(s) ECC corrected at 03e60000
065a0000: reading...
1 bit(s) ECC corrected at 065a0000
06e60000: reading...
1 bit(s) ECC corrected at 06e60000
0b560000: reading...
1 bit(s) ECC corrected at 0b560000
0c040000: reading...
2 bit(s) ECC corrected at 0c040000
0cc40000: reading...
1 bit(s) ECC corrected at 0cc40000
0cd80000: reading...
1 bit(s) ECC corrected at 0cd80000
0ce40000: reading...
1 bit(s) ECC corrected at 0ce40000
0da00000: reading...
1 bit(s) ECC corrected at 0da00000
0daa0000: reading...
1 bit(s) ECC corrected at 0daa0000
0f160000: reading...
ECC failed at 0f160000
0f5e0000: reading...
ECC failed at 0f5e0000
0f840000: reading...
ECC failed at 0f840000
14080000: reading...
1 bit(s) ECC corrected at 14080000
15460000: reading...
1 bit(s) ECC corrected at 15460000
15ae0000: reading...
1 bit(s) ECC corrected at 15ae0000
15e40000: reading...
1 bit(s) ECC corrected at 15e40000
161a0000: reading...
2 bit(s) ECC corrected at 161a0000
17740000: reading...
1 bit(s) ECC corrected at 17740000
17900000: reading...
1 bit(s) ECC corrected at 17900000
1a540000: reading...
1 bit(s) ECC corrected at 1a540000
1a860000: reading...
1 bit(s) ECC corrected at 1a860000
1aee0000: reading...
1 bit(s) ECC corrected at 1aee0000
1b4e0000: checking...
Finished pass 1 successfully
Does anyone know, why this call of nandtest utility damaged data on my card? Is any way how to call nandtest utility to have no damaged data?
It won't harm your flash. The error you saw just reveals your flash begins worn-out.
It is reported by flash driver.
-k option didn't do "the correction" as you think. It just restore data that previously existed on flash after testing.
Related
I am creating an Intel 8080 and was running a test ROM named TST8080.ASM that I found at this Webiste. I am failing when this block of code runs:
CPOI: RPE ;TEST "RPE"
ADI 010H ;A=99H,C=0,P=0,S=1,Z=0
CPE CPEI ;TEST "CPE"
ADI 002H ;A=D9H,C=0,P=0,S=1,Z=0
RPO ;TEST "RPO"
CALL CPUER
I just don't understand why on the ADI instruction the parity flag is not set. When converting 99H to binary I get 10011001 which is an even number of bits yet the tests seems to expect the parity flag to not be set. If anyone could shed some light I would be grateful... Thx
I have read the Intel 8080 Manual which states "Byte "parity" is checked after certain operations. The number of 1 bits in a byte are counted, and if the total is odd, "odd" parity is flagged; if the total is even, "even" parity is flagged. The Parity bit is set to 1 for even parity, and is reset to 0 for add parity.
Try this online 8080 emulator
Enter the code:
mvi a, 89h
adi 10h
Press step and observe that the parity bit is set:
AT+HTTPINIT
OK
AT+HTTPPARA="URL","http://api.openw⸮athermap.org"
OK
AT+HTTPACTION=0
OK
+HTTPACTION: 0,713,0
AT+HTTPTERM
OK
---------------------------
AT+HTTPINIT
OK
AT+HTTPPARA="URL","http://api.openw⸮
ERROR
AT+HTTPACTION=0
+HTTPACTION: 0,702,0
OK
AT+HTTPTERM
OK
I coding in Arduino IDE for SIMCom A7670C, I follow "A76XX Series_HTTP(S)_Application Note_V1.03" datasheet and "76xx AT Command" datasheet.
I have a problem with HTTPACTION, error code is 713 and 702. How should I solve it?
I used ESP8266 connect with SIMCom.
i am trying to get or put with TFTP protocol. I set the TFPT server and everything worked but stopped working lately. I am able to connect to the server but am getting an error "unknown option -?" when inspecting the Syslog. When running Tcpdump i see the message is "19 RRQ filename netascii"
i have looked for a couple of days in the net but with no success.
from RFC 1350
opcode operation
1 Read request (RRQ)
2 Write request (WRQ)
3 Data (DATA)
4 Acknowledgment (ACK)
5 Error (ERROR)
2 bytes string 1 byte string 1 byte
------------------------------------------------
| Opcode | Filename | 0 | Mode | 0 |
------------------------------------------------
This is what you have to see in your RRQ or WRQ packet
1, I want to know how much time spent on compile a class or method in hotspot during JIT (We got some timeout issue and we suspect it maybe caused by a long compilation time)? Is there any trace flag or other ways to trace this time?
2,BTW, if the method run on first time , then the compilation time would is 0 as there is totally no compilation process, right?
JVM flags: -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation2
289 425 4 java.time.LocalDate::until (116 bytes)
292 360 3 java.time.ZoneId::of (85 bytes) made not entrant
293 426 4 java.time.LocalDate::from (68 bytes)
293 386 3 java.time.LocalDate::from (68 bytes) made not entrant
293 426 size: 248(96) time: 0 inlined: 54 bytes
297 425 size: 3688(2272) time: 8 inlined: 1092 bytes
^ ^ ^ ^ ^
| | | | |
| | compiled bytes | bytecodes inlined
| compilation ID method compilation time (ms)
timestamp (ms from JVM start)
Note that
JIT compiler works in background while the application is running; it is unlikely to cause delays or timeouts.
There are typically multiple compiler threads; PrintCompilation output may appear interleaved.
A method may be (re)compiled multiple times with a different level of optimization.
jitwatch can record and display jit compilation logs.
When I synthesize an empty circuit using Yosys and arachne-pnr, I get a few irregular bits:
.io_tile 6 17
IoCtrl IE_1
.io_tile 6 0
IoCtrl REN_0
IoCtrl REN_1
These are also part of every other file I could generate so far. Since an unused I/O tile has both IE bits set, I read this as:
for IE/REN block 6 17 0, the input buffer is enabled
for IE/REN block 6 0 0, the input buffer is enabled and the pull-up resistor is disabled
for IE/REN block 6 0 1, the input buffer is enabled and the pull-up resistor is disabled
However, according to the documentation, there is no IE/REN block 6 17 0.
What is the meaning of these bits? If the IE bit of block 6 17 0 is unset because the block doesn't exist, why aren't the bits of the other blocks which don't exist unset, too? The other IE/REN blocks seem to correspond to I/O blocks 6 0 1 and 7 0 0. What do these blocks do, and why are they always configured as inputs?
The technology library entry for SB_IO does not mention the IE bit. How is it related to the PIN_TYPE parameter settings?
When I use an I/O pin as an input, the REN bit is set (the pull-up resistor disabled). This suggests that the pull-up resistors are primarily intended to keep unused pins from floating, not to provide a pull-up resistor for conditionally connected inputs (e.g. buttons). Is this assumption correct? Would it be ok to use the internal pull-up resistors for that purpose?
The technology library says the following:
defparam IO_PIN_INST.PULLUP = 1'b0;
// By default, the IO will have NO pull up.
// This parameter is used only on bank 0, 1,
// and 2. Ignored when it is placed at bank 3
Does this mean bank 3 doesn't have pull-up resistors, or merely that they can't be re-enabled using Verilog? What would happen if I clear that bit in the ASCII bitstream manually? (I'd be trying this, but the iCEstick evaluation board doesn't make any pin on bank 3 accessible – a coincidence? – and I'm not sure if I want to mess with the hardware yet.)
When I use an I/O pin as an output, the IE bit isn't cleared, but the input pin function is set to PIN_INPUT. What effect does this have, and why is it done?
The default behavior for unused IO pins is to enable the pullup resistors and disable input enable. On iCE40 1k chips this means IE_0 and IE_1 are set and REN_0 and REN_1 are cleared in an unused IO tile. (On 8k chips IE_* is active high, i.e. all bits are cleared in an unused IO tile on an 8k chip.)
icebox_explain by default hides tiles that have "uninteresting" contents. (Run icebox_explain -A to disable this feature.)
It looks like arachne-pnr does not set those bits for IO pins that are not available in the current package. Thus you get some unusual bit pattern in some IO tiles that contain IE/REN bits for IO blocks not connected to any package pin.
This is what a "normal" unused IO tile looks like on the 1k architecture:
$ icebox_explain -mAt '1 0' example.asc
Reading file 'example.asc'..
Fabric size (without IO tiles): 12 x 16
.io_tile 1 0
B0 ------------------
B1 ------------------
B2 ------------------
B3 ------------------
B4 ------------------
B5 ------------------
B6 ---+--------------
B7 ------------------
B8 ------------------
B9 ---+--------------
B10 ------------------
B11 ------------------
B12 ------------------
B13 ------------------
B14 ------------------
B15 ------------------
IoCtrl IE_0
IoCtrl IE_1
Would it be ok to use the internal pull-up resistors for that purpose?
Yes.
The technology library entry for SB_IO does not mention the IE bit. How is it related to the PIN_TYPE parameter settings?
When D_IN_0 or D_IN_1 from SB_IO is connected to something, then this implies IE.
When I use an I/O pin as an output, the IE bit isn't cleared
Note that IE is active low on 1k chips and active high on 8k chips. When you use an I/O pin as output-only pin on a 1k device, then the corresponding IE bit should be set, otherwise it should be cleared.
I found the explanation, so I'm sharing it here for future reference:
.io_tile 6 17
IoCtrl IE_1
I/O block 16 7 0 is connected to a pin in some packages but not in the TQFP package.
.io_tile 6 0
IoCtrl REN_0
IoCtrl REN_1
This corresponds to I/O blocks 6 0 1 and 7 0 0 (pins 49 and 50) into whose input paths the PLL PORTA and PORTB clocks are fed, respectively.