Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tcf-dev] TCF and microcontrollers/uC (e. g. AVR or ARM Cortex)

Hi Rainer,

proxy.c and proxy.h can be used to redirect TCF commands to another agent, optionally adding more services.
It will not help with translation of a completely different proprietary protocol to TCF protocol.

If the proprietary protocol is low-level debug protocol, and you want to translate it to TCF while adding source-level debugging capabilities, then it is same case as JTAG debugger. In short, you will have to implement context-dispatcher.h interface on top of the proprietary protocol. One example of such protocol would be GDB serial.

Other types of protocol translation are possible, but not directly supported by open source TCF code.

Regards,
Eugene


-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Rainer Poisel
Sent: Friday, February 27, 2015 1:51 PM
To: TCF Development
Subject: Re: [tcf-dev] TCF and microcontrollers/uC (e. g. AVR or ARM Cortex)

Hi Eugene,

thank you very much for your comprehensive reply! It will definitely
be helpful. Hopefully, I will have some time soon to get a deeper
understanding of how OpenOCD actually works in order to be able to
integrate it.

Thanks for the information that it does not make much sense to
implement a TCF agent in Java. We have developed some custom TCF
services which I want to make available with different internal
implementations.

E. g. it is possible to read values of variables used in programs
running on our target systems. We have a custom TCF service for that.
There are a few different types of target systems in place, i. e. one
has a built-in TCF agent, another one offers the same functionality
but is accessible through a completely different proprietary protocol
and another one is accessible through RS232 only.

Now I would build some kind of bridge that translates requests to our
TCF agent to whatever a specific target system types needs to be
accessed.

Or would this scenario be a use case for the proxy module (proxy.c and
proxy.h) of the TCF framework?

  Rainer


On Tue, Feb 24, 2015 at 10:39 PM, Eugene Tarassov
<eugene.tarassov@xxxxxxxxxx> wrote:
> Hi Rainer,
>
>> What would be the starting point for implementing such a bridge?
>
> In Linux or CygWin shell, do:
>
>   cd org.eclipse.tcf.agent/agent
>
>   git pull
>
>   make 'CFLAGS=-DENABLE_ContextProxy=1 -DENABLE_ContextMux=1 -DENABLE_StackCrawlMux=1 -DENABLE_ContextIdHashTable=1 -DENABLE_PE=0 -DENABLE_ELF=1 -DSERVICE_Processes=0 -DSERVICE_Terminals=0 -DSERVICE_SysMonitor=0' clean all
>
> Linker will fail because init_contexts_sys_dep is undefined. It is the function you have to implement.
>
>> Or what would be the missing 10% of code?
>
> In your init_contexts_sys_dep(), you open JTAG cable and use post_event_with_delay() to poll and auto-detect JTAG chain periodically. For each device found in the chain, you create a debug context, or several contexts if the device is something like multi-core CPU. For example:
>
>     Context * ctx = create_context(id);
>     context_set_interface(ctx, jtag_ctx_if);
>     ctx->name = loc_strdup("Cortex A9 Core #0");
>     ctx->mem = ctx;
>     ctx->mem_access |= MEM_ACCESS_INSTRUCTION;
>     ctx->mem_access |= MEM_ACCESS_DATA;
>     list_add_last(&ctx->ctxl, &context_root);
>     send_context_created_event(ctx);
>
> Where ContextIf * jtag_ctx_if is a collection of function pointers, which implements low-level debugger back-end. You need to implement all those functions, or borrow implementation from OpenOCD. This is the missing 10% of code
>
>> I think that I would need to implement both the interfaces in the "machine" as well as the "system" directory of the agent source?
>
> No, you don't need that. At least, not for ARM. For other CPUs, you might need to add disassembler and/or stack tracing code in the "machine" directory.
>
>> Aside from that, would it be possible to implement a TCF agent (i. e. the bridge) in JAVA as well?
>
> Not really. It could be done by translating all TCF agent C code to Java. It would be huge amount of work.
>
> Regards,
> Eugene
>
> -----Original Message-----
> From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Rainer Poisel
> Sent: Tuesday, February 24, 2015 4:33 AM
> To: TCF Development
> Subject: Re: [tcf-dev] TCF and microcontrollers/uC (e. g. AVR or ARM Cortex)
>
> Hi Eugene,
>
> thanks for your response. That sounds interesting to me. What would be
> the starting point for implementing such a bridge? Or what would be
> the missing 10% of code?
>
> I think that I would need to implement both the interfaces in the
> "machine" as well as the "system" directory of the agent source? After
> studying the "TCF agent porting guide" and the "TCF Agent Prototype
> Implementation" documents it is not completely clear to me.
>
> Aside from that, would it be possible to implement a TCF agent (i. e.
> the bridge) in JAVA as well?
>
> Regards,
>   Rainer
>
>
> On Mon, Feb 23, 2015 at 7:48 PM, Eugene Tarassov
> <eugene.tarassov@xxxxxxxxxx> wrote:
>> Hi Rainer,
>>
>>> Would TCF be suitable for communicating with systems that do not have an operating system such as microcontrollers?
>>
>> Sure. One way to do is to use JTAG. TCF provides over 90% of code needed to build very powerful JTAG debugger. In such case, TCF agent runs on a host and communicates with the microcontroller over JTAG cable.
>>
>> Regards,
>> Eugene
>>
>> -----Original Message-----
>> From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Rainer Poisel
>> Sent: Sunday, February 22, 2015 10:59 PM
>> To: TCF
>> Subject: [tcf-dev] TCF and microcontrollers/uC (e. g. AVR or ARM Cortex)
>>
>> Dear list,
>>
>> recently I have spent some time on learning what TCF is and how things
>> actually work. To me it's an impressive and powerful framework. Now I
>> was wondering:
>>
>> Would TCF be suitable for communicating with systems that do not have
>> an operating system such as microcontrollers?
>>
>> My use cases would be to download code or to debug downloaded code. I
>> stumbled upon the TCF porting guide
>> (http://git.eclipse.org/c/tcf/org.eclipse.tcf.git/plain/docs/TCF%20Agent%20Porting%20Guide.html)
>> and I have seen that Xilinx supports TCF for their devices.
>>
>> Regarding the ARM Cortex devices (e. g. STM32F4) - is there anything
>> available yet for these 32-bit microcontrollers? I don't know whether
>> the Xilinx approach works for all ARM Cortex microcontrollers. I have
>> used the CDT together with GDB to debug applications but would it be
>> possible with the TCF as well?
>>
>> And how about even more resource limited devices such as AVR microcontrollers?
>>
>> What would be the preferable approach to support such devices -
>> implementing a TCF agent that runs on a host and works as a bridge to
>> the microcontroller (e. g. TCF over TCP/IP to a custom serial
>> protocol) or running a stripped down agent implementing the serial
>> protocol directly on the microcontroller?
>>
>> Thanks in advance for giving me a few hints,
>>   Rainer
>> _______________________________________________
>> tcf-dev mailing list
>> tcf-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/tcf-dev
>>
>>
>> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>>
>> _______________________________________________
>> tcf-dev mailing list
>> tcf-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/tcf-dev
> _______________________________________________
> tcf-dev mailing list
> tcf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/tcf-dev
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
> _______________________________________________
> tcf-dev mailing list
> tcf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/tcf-dev
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tcf-dev


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.



Back to the top