3

I Have a PC Program that is communicating over a TCP/IP Connection to an Embedded board (Infineon XE169 (C166 Family)).

This PC Program request what data is stored on a certain address. The PC Program is uC/Probe, and I cannot change how this program is working.

uC/Probe for example sends this message:

 ____________________________________________________________________________________________________________
|     Prefix         | Length    |Pkt_nr|Unused| Format    | read size | Address to read      |Unused|Postfix|
|--------------------|-----------|------|------|-----------|-----------|----------------------|------|-------|
|0x75 0x43 0x50 0x72 | 0x00 0x08 | 0x00 | 0x00 | 0x02 0x00 | 0x04 0x00 | 0xDC  0x3E 0x61 0x00 | 0x00 | 0x2F  |
|u    C    P    r    |   8       | 0    |  0   | 2         | 4         | 0x613EDC             | 0    | /     |   
|____________________|___________|______|______|___________|___________|______________________|______|_______|

This is a message to request the data from address 0x613EDC and read 4 bytes from there.

When looking in the .map file I can see that at this location the OSTCBCurPtr variable is placed. This variable is an OS_TCB* thus at the requested address is the address placed where this variable is pointing to.

I've now manually looked in the .map file what kind of variable is placed on the address. But can I get the variable type trough the C code on the Embedded board. All I want to know is if the object that lies on that specific location is a pointer or not, if it's an uint16_t, uint8_t, char or whatever is unimportant to me.

Background information, why I want to know this

The Embedded board will sent back the requested data to the uC/Probe program. But the pointers are stored in a strange way in the XE169 chip. The pointer of above example is for example stored like this:

 _______________________________________
| Address   |  0   |   1  |  2   |  3   |
|-----------|------|------|------|------|
|0x00613EDC | 0xE6 | 0x1F | 0x84 | 0x01 |
|___________|______|______|______|______|

Because the value's are stored little endian this would result in the number 0x01841FE6. This number is currently send back to uC/Probe. But his number isn't the correct location of the, a little calculation has to be done to get to the actual address location.

We have to take apart this 32bits number and split it into 2 16 bit numbers. Then we get:

Hex:  0x0184             and 0x1FE6
Bits: 0b0000000110000100 and 0001111111100110

Now the 16 upper bits have to move 2 bits to the right. The 2 least significant bits of these upper 16 bits become the 2 most significant bits on the lower 16 bits.

This results into:

Hex:  0x0061             and 0x1FE6
Bits: 0b0000000001100001 and 0001111111100110

When we paste these 2 16 bit numbers back to the 32 bit number we have the address where the pointer is pointing to: 0x00611FE6

And this is the number I have to sent back to uC/Probe. This calculation only has to happen for when uC/Probe requests pointers, for non pointers it just needs to send back the data read from the given address. That's why I need to know if the requested data is a pointer, hopefully someone can help me with this.

Roel Balink
  • 417
  • 1
  • 4
  • 19
  • ͏+͏1͏, alas though there is no *portable* way of telling (I'd plump for an inline assembly hack.). Any solution will depend on your compiler and architecture. Could you specify those in plain terms please? – Bathsheba Mar 14 '18 at 11:34
  • 1
    The .map file is readable ASCII? Then you can write a small C programto parse it and store the information relevant for you in a data structure that you can use to analyze the data you get back from the board. – Paul Ogilvie Mar 14 '18 at 11:54
  • 1
    "We have to take apart this 32bits number and split it into 2 16 bit numbers. Now the 16 upper bits have to move 2 bits to the right." This is known as **segment offset addressing**. (I fiddled a lot with this back these days where we did programming for Intels 8086.) I found a Q/A concerning this: [SO: How does the segment:offset addressing scheme work?](https://stackoverflow.com/q/8694950/7478597). Just for your interest... – Scheff's Cat Mar 14 '18 at 12:37
  • I am afraid that you are trying it backwards. It is uC/Probe which is aware of the image layout and data types. Look at the `Format` field, and format the reply accordingly. – user58697 Mar 14 '18 at 17:33
  • @Bathsheba too bad there isn't a portable way to fix this. What exactly do you mean by specifying the compiler and architecture settings in plain terms? The chip is one of the C166 Family. Not sure if this is what you mean, but this are my Compiler options: [link](https://dl.dropboxusercontent.com/s/lhlx4zf5e5ufais/Compiler%20options.JPG?dl=0) – Roel Balink Mar 15 '18 at 07:51
  • @PaulOgilvie This seems like a smart workaroud, maybe I could create some kind of gateway program that converts the addresses. the .map file is a readable file in .xml format, but maybe I should use the .elf file, the .elf file contains the object types and if it's a pointer or not. The .map file doesn't have that, but I saw it was a pointer based on the variable name. – Roel Balink Mar 15 '18 at 07:52
  • @Scheff Good to know that there is a name for this formatting structure, this might make searching for these pointer problems a lot easier. – Roel Balink Mar 15 '18 at 07:52
  • @user58697 I know uC/Probe is aware off the data types and where they are stored, but uC/Probe doesn't seem to be aware off the fact that these pointers are stored in a different way. uC/Probe doesn't seem to handle these pointers correct. And I don't think I can tell uC/Probe that the chip has this kind of **segment offset addressing** (how this Phenomenon is called as told by Scheff ) – Roel Balink Mar 15 '18 at 08:00
  • @RoelBalink Let me clarify: you don't _tell_ uC/Probe how the address is stored. Instead, once you realized that uC/Probe asks for the address, it is _your_ responsibility to format the reply in the way uC/Probe understands. Of course it is not cross-platform, and must be performed by the platform code. – user58697 Mar 15 '18 at 18:34
  • @user58697 I understand that. That is why I originally asked this question. I need to know when a pointer is requested by uC/Probe so that I can format the response to a correct pointer location, which is understood by uC/Probe. – Roel Balink Mar 19 '18 at 11:20

0 Answers0