Hi,

 

Following my previous email (which you might not have received yet, because the attached snapshot was slightly over the size limit), I have written a small patch to address the issue I found with ETMv4 decoding.

 

For clarity, the issue I encountered was that in EtmV4ITrcPkt::updateShortAddress, when the v_addr field is computed, it uses the old value (which is supposed to be the last broadcast address, according to the documentation).

However, when an Exact Match packet is output, the specification says that the matched address is pushed at the front of the address queue.

The v_addr field looks to me like it is the top of the address queue, so should be updated in EtmV4ITrcPacket::setAddressExactMatch, which is currently not done.

 

The patch I wrote replicates the address queue in the EtmV4ITrcPacket class, to update the last broadcast address accordingly when reading an exact match.

There is a bit of redundancy, because it is also done in the TrcPktDecodeEtmV4I class, but it seems to fix the problem.

 

You will find the patch attached to this email.

 

Below is the output for the section that showed an incorrect output.

Idx:4248; ID:12;        I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004DC2DC ~[0xDC]

Idx:4250; ID:12;        I_ATOM_F3 : Atom format 3.; EEN

Idx:4251; ID:12;        I_ATOM_F2 : Atom format 2.; EE

Idx:4252; ID:12;        I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004D004C ~[0x1004C]

Idx:4256; ID:12;        I_ATOM_F1 : Atom format 1.; E

Idx:4257; ID:12;        I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004DCC6C ~[0x1CC6C]

Idx:4260; ID:12;        I_ATOM_F3 : Atom format 3.; EEN

Idx:4261; ID:12;        I_ATOM_F3 : Atom format 3.; NNE

Idx:4262; ID:12;        I_ATOM_F3 : Atom format 3.; EEN

Idx:4263; ID:12;        I_ATOM_F2 : Atom format 2.; EE

Idx:4264; ID:12;        I_ADDR_MATCH : Exact Address Match., [1]

Idx:4265; ID:12;        I_ATOM_F1 : Atom format 1.; E

Idx:4266; ID:12;        I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004D00F4 ~[0xF4]

 

The last address is constructed from 0x004D004C, which is at the top of the address queue after the Exact Match.

Before the patch, it was constructed from 0x004DCC6C, which was at the top of the address queue *before* the Exact Match, and at index 1 after.

 

I hope you can add this patch to the library at some point, or a modified version of it.

 

Best regards,

 

Thierry Laviron

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.