Details
-
Type:
Bug
-
Status: Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: V1.6.0, V1.7.0
-
Fix Version/s: V1.8.1
-
Component/s: None
-
Labels:None
-
Account:SCT CLIFlasher operational (CLIFLASHER)
Description
First CLI Flasher Call (to set up error situation)
- Host sends a command to the netX
- netX answers with ACK packet
- netX sends answer for the command
- Host sends ACK (ACK packet gets lost)
Now the netX is still resending the answer packet and is waiting in an endless loop for the ACK packet.
Case1: Second flasher call (via ethernet_mi) - fixed with NXTFLASHER-317
- Knock packet is sent (inside synchronize() function inside reomloader.cpp)
- wrong answer is received
- cancel operation packet is sent to get netX out of endless loop
- Knock packet is sent again
- Correct Answer from netX is received
Case1: Second flasher call (via uart_mi)
- First communication is not insice synchronize() but inside identify_loader()
- identify_loader() is missing the cancel operation that is used inside synchronize()
Attachments
Issue Links
- relates to
-
NXTFLASHER-317 M2M: Send Cancel_Operation packet, when knock gets a packet as response that is not "MagicData" packet
-
- Resolved
-
-
NXTFLASHER-449 UART interface: ACK packet gets lost and netX stucks inside endless loop
-
- Resolved
-
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...