Previous Article covered getting iB-IDE up and running despite old dependencies. This time, we'll look at what happens internally when you communicate with the Java Ring from within iB-IDE.

Just Trying It Out...#

Since iB-IDE has a feature to send APDU commands, I started by trying Get Firmware Version ID. Presumably, this would return the firmware version from the ring.

Hmm.

It seems there's an error related to CRC.

Let's Do Some Calculations#

I decided to calculate the checksum manually first.

The response from the ring was a byte sequence like this:

55 16 94 03 07 00 00 00 D0 E1 FE FF FF FF FF FF

According to the documentation, every command starts with 55, and indeed, the response also begins with 55. This suggests that my Java Ring is not irreparably broken (per firmware).

Plugging this into a Dallas-style CRC should yield 45057 if everything's right.

The actual formula for the CRC is as follows:

Upon calculation, however, I got 57343, not 45057. Why?

Understanding the Situation#

Initially, I thought it might be a problem with the CRC calculation or that my Java Ring was broken. However, after debugging by inserting standard output, things seemed more complex.

In reality, there are two CRC checks. The first one succeeds, but the second fails.

The logs show an initial response like this:

0x55, 0x16, 0x94, 0x03, 0x07, 0x00, 0x00, 0x00,
0xD0, 0xE1, 0x08, 0x00, 0x40, 0x00, 0x70, 0x49

This passes the CRC check. Therefore, at least initially, meaningful responses are coming from the Java Ring.

Power-On Reset Failure#

Upon reviewing the logs again, it appears that a Power-On Reset (POR) failure is reported first.

POR is a process to discard any intermediate states after powering up and start fresh. In my case, this POR seems to be failing multiple times, leading to CRC errors.

Summarizing Behavior#

Here's what happens from power-on to error:

1. The 1-Wire API recognizes the Java-powered iButton.
2. checkStatus calls getStatus.
3. Uses 0x55, or MATCH ROM, to specify the destination and issue a status retrieval command.
4. Receives a response from the Java Ring.
5. This response passes CRC checks.

The returned response roughly looks like this:

ROM Command | ROM ID | Command Name | Arguments/Response

For the status command, 08 00 40 00 is received. This status 40 means "reset the device to correct POR."

Attempting to Correct POR#

Upon receiving status 40, the correctPOR method is called. This method roughly performs:

1. reset
2. setStatus(trial count)
3. run(trial count)

The reset method sends 0xDD, 0xBC, 0x92 to request a reset. Details of the other two methods are still under investigation.

After POR correction attempts, status retrieval and environmental adaptation operations run again within checkStatus. For some reason, the device returns almost all FF.

55 16 94 03 07 00 00 00 D0 E1 FE FF FF FF FF FF

This leads to a failure in the second CRC check.

Summary So Far#

Here's what we've learned:

1. Initial status retrieval yields meaningful responses from Java Ring.
2. The first CRC check passes.
3. Status 40 triggers POR correction processing.
4. Post-POR correction, status retrieval returns mostly FF.
5. This second response fails the CRC check.

While details remain unclear, it seems communication isn't entirely broken. I'll continue investigating.

Conclusion#

What do you think?

In this article, we confirmed that Java Ring is treated as a Java-powered iButton and attempted communication. Despite getting responses, mysterious CRC errors blocked further progress. Next time, I'll dig deeper into these issues.

Until then!

Previous: 【Java Ring】04. Running iB-IDE
Next: 【Java Ring】06. Battery Replacement Seems Necessary