Hello Sabina and all others,
In the meanwhile, the issue have been solved. As feedback from a colleague, I got a helpful tip. In an interrupt based I2C communication, the AA setting is not for the current byte which is received instantly with this interrupt, but always for the next byte waiting in the I2C sender. When I set AA in CONSET, I signal to the sender I am willing to take the next byte. But when I set AA in CONCLR I signal that I want to terminate the communication with the next byte. If I read the final byte, I only set STO in CONSET and do not need to set AA anymore.
Unfortunately, you will not find any word about this behavior in the I2C section of the user manual UM10430 of the LPC18S37.
Please allow me one word to the A7000 security controller. I use an official NXP demo board OM13076 (a schematic is also available) which contains a LPC18S37 Cortex-M3 controller and a A7000 Secure Element (SE). In my application I store card keys on the A7000 and allow remote users to authenticate theirs cards with keys saved inside of the A7000. The benefit of the A7000 is that you can write your own software and save it in the SE. Finally, the A7000 is locked with special keys against unauthorized access and only such commands which you have implemented are able to be used for the outside communication. For me the A7000 is the perfect solution for a security application.
If anybody in the community is interested in the A7000, please take in mind the A7000 is a security product and any user must sign an NDA with NXP to get datasheets and application notes.
Sabina, as you can see, my question did not affect any security internals of A7000 and was solved by changing the I2C controller behavior of the LPC18S37.
Thank you very much for your effort to solve this issue.
Wolf
