We are running interface tests between our IAP binary loader and the Windows ARMWSD.exe.
- ARMWSD.exe throws a lot of undocumented character strings at the binary loader so we have to filter all input for the 0x07/0x0E, byte-pair, start-of-binary record. It would help a great deal if there was a specification for the ARMWSD.exe binary loader interface.
Following the command to erase two 512-byte blocks, 0x1800 and 0x1A00, ARMWSD.exe sends the following binary record for writing four bytes to 0x1800:
- 0x07 0x0E 0x09 0x57 0x00 0x00 0x18 0x00 0x18 0xF0 0x9F 0xE5 0xFC
- We write the four bytes to FLASH with successful FEESTA returns and ACK the WRITE command.
Despite the ACK returns, ARMWSD.exe keeps sending the binary loader the same WRITE command ten more times before we finally get an unsuccessful FEESTA return and NAK ARMWSD.exe accordingly. ARMWSD.exe then reports that the FLASH write failed.
What is the problem getting ARMWSD.exe to recognize our ACK returns - it recognized the ACK returns for the two 512-byte erases?
- The only thing I can think of is that ARMWSD.exe is timing out the WRITE command before the ACK gets back to him. If that is true, we have a real problem, because the timing is mostly relegated by the time it takes to get a successful FEESTA return relative to the current FLASH operation.
The binary loader works with our Linux compatible equivalent to ARMWSD.exe but not with ARMWSD.exe. I think the reason for our struggle is that we need the specification for the ARMWSD.exe binary loader interafce.
The ARMWSD.exe interface specification is begining to look like the following:
WRITE records are sent out for checksum acknowledgement - not FLASH operation acknowledgement.
The binary loader is expected to queue the binary WRITE records for later dequeueing and writing.
When ARMWSD.exe goes into VERIFY mode he waits longer for the return acknowledgements to the VERIFY binary records.