I2C stops working if Segger or CMSIS-DAP is used

[jrychter]

In the process of bringing up my board based on a K20, I encountered problems with I2C. I would initialize I2C and load the first address byte, but then I'd get no interrupts, ever.

This was strange, because the I2C code is my own (https://github.com/jwr/kinetis_i2c/tree/cmsis), and I used it before with no problems.

I'm using KDS 3.0.0 (updated) under Linux, with Segger J-Link to connect to my board.

So I started looking at my recent code changes, clocking, all kinds of possible problems. I also took out a FRDM-K20D50M board (Segger debug firmware) just to be sure that I can reproduce the problem in a pristine environment. The problem was the same on the FRDM board.

I brought up an old virtual machine with CodeWarrior 5.5 and some old I2C project that used to work — same result, none of them worked. I was sure they worked before. This was getting weird.

In an act of desperation, I decided to reflash the OpenSDA part of the FRDM-K20D50M, just to see if using the P&E debug firmware would give me a better view of the registers. This took quite a while, because I had an old 1.09 bootloader, which can't be updated using any modern OS. Luckily I had an ancient VMware snapshot with Windows XP!

And suddenly things started working again.

I did some more testing and I don't understand the results. Here's a breakdown:

• my board + Segger J-Link -> I2C does not work
• FRDM + Segger firmware -> I2C does not work
• FRDM + P&E firmware -> I2C works
• FRDM + bootloader only (booted in firmware update mode) -> I2C works
• FRDM + CMSIS-DAP firmware -> I2C does not work

On the FRDM board, it seems that just the presence of Segger or CMSIS-DAP firmware prevents I2C from working. It doesn't matter if I'm debugging — just hitting RESET with P&E firmware present produces an I2C transaction, and with Segger or CMSIS-DAP firmware present it does not.

When stepping through the code, everything looks fine up to a certain point. I2C module is initialized, interrupts get enabled, master mode is set and a start condition generated. But then I write to the D register and... nothing happens. I get no interrupts. A bus sniffer shows only a start condition being generated.

The firmware versions I used for testing are: JLink_OpenSDA_2015-10-13.sda, CMSIS-DAP_OpenSDA.S19, MSD-DEBUG-FRDM-K20D50M_Pemicro_v115.SDA.

Frankly, I have no idea what to make of this, which is why I'm asking for help. Leaving aside my board for now, on the FRDM — I can't understand how just the presence of certain OpenSDA debug firmware could influence how my code works.

Any ideas?

[jrychter]

It seems that the KDS 3.1.0 update fixed the problem — at least with a Segger J-Link I2C started working again.

[Jorge_Gonzalez]

Hello Jan:

Sorry, I was in PTO. I could not get any further finding the cause of this issue. It's good to know you got J-Link working with the new update.

I've seen you have another post related to FRDM-K22F (here). I am not very knowledgeable in the workings of GDB but I hope Erich can give you some good hints.

Hope you have a good New Year!

Regards!

Jorge Gonzalez

[Jorge_Gonzalez]

Hello Jan Rychter:

Just to confirm, does the issue only happen in Debug mode or also in standalone mode?

Could you share a binary or even better the I2C test project to investigate this?

At this moment I cannot think of the reason, but if it's in Debug mode then we have seen issues for example with the NMI pin, as explained in the next post:

Interrupts appear to be disabled when debugging.pdf

Regards!

Jorge Gonzalez

[jrychter]

Ok, I extracted a minimal example. I tried running this on a FRDM-K20D50M, with two debug configurations:

1. Segger J-Link OpenSDA firmware

2. PEMicro OpenSDA firmware.

I set a breakpoint in the I2C0_IRQHandler. In the first case, the handler never gets called. In the second case, it does get called several times, as it should, and the device_id variable in the main() function contains the correct value 0x1a (as read from the on-board accelerometer).

The entire project (including the binaries) is at:

https://dl.dropboxusercontent.com/u/448282/I2C%20Debug.tar.gz

[Jorge_Gonzalez]

Hello Jan:

Just as an update, I found the same issue as you, but this is related to the debug interface application and I've not found the time to investigate further. For the J-Link case, the code works if I connect the Freedom board in BOOTLOADER mode (pressing reset while connecting the board).

In the meantime you can go with the P&E interface.

Regards!
Jorge Gonzalez

[jrychter]

I wonder — have you found any time to look at this? It is a showstopper for one of my projects, where I can't use a FRDM board.

[jrychter]

Jorge,

On the FRDM board I can use the P&E interface, but I don't have that option with my own boards, as I can only connect to them using a Segger J-Link. So I'd really like to get to the bottom of this.

I'm glad you could reproduce the problem — any chance you will investigate further?

thanks and best regards,

--Jan

[jrychter]

I only tested with a debugger connected — so I do not know if the same thing happens without a debugger (if that's what you mean by standalone mode).

The NMI issue explanation would actually fit, but another part of the code uses DMA and DMA0_IRQHandler does get called just fine. It's just I2C that doesn't seem to work. From what I understand, a hanging NMI exception would disable all interrupts.

I guess I have to extract a minimal example, then.