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,

> 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.

Back to the top