Datasheet Error regarding I2C Description

In the Apalis TK1 datasheet (up to V1.2A Oct 2018), Table 6-26 (I2C Signals), the I2C Port I2C4 of the TK1 SoC is described as for the camera interface, and port I2C3 is described as for DDC. These descriptions are interchanged, as all other mention of these ports, even in the same table, indicate that I2C4 is for DDC and I2C3 is CAM.

I found this while debugging a suspected faulty DDC I2C channel on a TK1 SOM, which I will be returning for RMA.

Actually, I discovered the TK1 is not faulty but is revision V1.2A. Per question 22545 in this forum, we need to be running BSP 2.7b5 for the EDID to work. Our client is forced to continue with 2.7.2 for library compatibility reasons but since the V1.1A will be MD’ed, they now have to scramble to fix the display driver or figure out an EDID-less approach to driving their custom display.

hi @RPHILLE

Thanks for this Information. Your customer should really update to at least Bsp 2.7 Stable release. The older versions are not supported anymore.

Best regards, Jaski

That’s not an option for them at the moment as their product relies heavily on the CUDA libraries NVIDIA released with the TK1 JetPack.

Back to the topic of the I2C change in V1.2A, was there a compelling technical reason that the I2C swap had to include signals that were not related to I2C (USBH_EN and USBH01_EN)? Our client system design uses those two USB signals and this greatly complicates the rework of their existing V1.1A supporting custom carriers to support 1.2A SOMs running 2.7.2 BSP. It would have been so much easier if just the GPIO3/4 and I2C2_(DDC) were swapped.

Since I first posted this query, we had successfully up-rev’ed our carrier design to account for the new pin assignments. The concerns about display driver have also been relieved.

Just want to confirm that datasheet V1.4 (08 Oct 2018) that I quoted last year is still the current version. If so, the Description error I pointed out in table 6-26 remains. A further confusion to this is that the SOM port I2C2 on pins 205/207 is served by the SoC I2C port 4. The first paragraph of section 6.8 refers to the SoC port ID, not the defined SOM pin ID. Fortunately, the signal names on both the SOM pins and the TK1 balls appear to be consistent. The Apalis Carrier Design Guide aligns with the SOM pin definitions and the descriptions are correct, so the error seems to be limited to the datasheet table 6-26.

Hi @RPHILLE

Thank you for reporting the issue. I had to check it twice until I found the issue. I can confirm that the description is swapped for the Apalis I2C2 (DDC) and the I2C3 (CAM). The rest of the table is correct. The I2C2 on pin 205/207 is the one that is reserved for the DDC while the I2C3 (pin 201/203) is intended to be used for the camera.

I have created a ticket. We will correct the table in the next revision of the datasheet.

I assume then you will continue to refer to the SoC port ID rather than the SOM pinout ID in section 6.8.
Can you also clarify whether the I2C port numbering in the datasheet is zero-based or one-based? The table in section 4.5 seems to imply that it is one-based but it is hard to tell definitively since neither I2C0 or I2C5 are present, the former indicating zero-base and the latter indicating one-base. This is often a source of confusion for developers.

Hi @RPHILLE

Thanks for your feedback.

Best regards,
Jaski

The reason for the “bigger” swap from Apalis TK1 V1.1 to V1.2 was compatibility with the Apalis standard. Let me explain:
I think it’s clear why we had to change the DDC signals. As described in Errata #7 in our errata document we had to use other signals to have better logic levels for DDC monitors and circuits on carrier boards. We had to take the signals which were used as GPIO3 and GPIO4 on the V1.1 Apalis TK1. To replace them, we had to take signals which are fully 3.3V capable for input and output! Unfortunately, the signals used for DDC in V1.1 are not 3.3V capable. That’s why we moved them to signals with a fixed function (USBx_EN) and added level shifters as the direction of these standard Apalis signals area output always. To fill now the gap on GPIO3 and GPIO4 on V1.2 Apalis TK1, we took the formerly USBx_EN singals which are also normal 3.3V GPIOs.
I hope this swap makes sense to you now.
We will try to help with your question about how to proceed now in your design in the new question you added here:
https://www.toradex.com/community/questions/32579/carrier-modification-not-possible-for-tk1-v12a-to.html
Or let us know if you need any further input on this question here too.

Hi @RPHILLE
I agree the I2C port numbering is confusing. The problem is that we have the Apalis Signal Names which should be consistent over different Apalis modules. These names start with 1. When we did the first Apalis module, we decided to call the names I2C1, I2C2, and so on.

Unfortunately, on the Apalis TK1, the SoC names the I2C ports the same way. They also start the ports with 1. These names are listed in the “I2C Port” column of the table. Additionally, the module features the K20 companion microcontroller which features also I2C ports. These ports start with 0.

I also agree that the text in section 6.8 is not very clear. The ports that are mentioned in this section are the TK1 SoC port names. Maybe have a look into the Toradex Pinout Designer Tool. In this too, you see how the different ports map together.

Thanks for confirming the number convention; it closes the loop on the statement in 6.8. I guess the decision was made to omit mention of the SoC I2C5 from table 4.5 due to it being used internally on the SOM. Fair enough.

I had also seen the K20 zero-base numbering but we are not using that MCU at all so our focus was strictly the SoC.

I consider this query answered.

Thanks for confirming the number convention; it closes the loop on the statement in 6.8. I guess the decision was made to omit mention of the SoC I2C5 from table 4.5 due to it being used internally on the SOM. Fair enough.

I had also seen the K20 zero-base numbering but we are not using that MCU at all so our focus was strictly the SoC.

I consider this query answered.