UDOO NEO programming/debug M4

Discussion in 'General Discussion' started by tcmichals, Feb 25, 2015.

  1. tcmichals

    tcmichals Member

    Joined:
    Feb 25, 2015
    Messages:
    54
    Likes Received:
    27
    - Is it possible to use arm-elf-none-edbi-gdb on the ARM9 to debug code running on the ARM M4? So, no need to attach SWD/JTAG and take pins
    - How is the code loaded onto the M4? i.e remoteproc?
    - Is there some IPC between the two processors (Linux/RTOS)? i.e remotemsg?
     
  2. Andrea Rovai

    Andrea Rovai Well-Known Member

    Joined:
    Oct 27, 2014
    Messages:
    1,703
    Likes Received:
    240
    Hi there,
    for the moment we are getting started with UDOO Neo, so it is better to wait before answering. Please, be patient :)
    Andrea
     
  3. juaperser1

    juaperser1 New Member

    Joined:
    Apr 13, 2015
    Messages:
    2
    Likes Received:
    0
    I have the same question please inform when possible.

    Payment tool is needed? as desing studio 5 arm.

    I would like programming and debug tools open source
     
  4. bobc

    bobc New Member

    Joined:
    Apr 30, 2015
    Messages:
    1
    Likes Received:
    0
    Yeah, I am wondering how the M4 programming will work as well! In theory, it could be fast and seamless compared to a serial connection, but getting all the magic to work inside one chip is a lot of work.. The IMX6SoloX is quite a beast!

    I'd be happy if it was just a "virtual serial" connection (via whatever mechanism), if that was robust.
     
  5. tcmichals

    tcmichals Member

    Joined:
    Feb 25, 2015
    Messages:
    54
    Likes Received:
    27
    Any update on this?
     
  6. Andrea Rovai

    Andrea Rovai Well-Known Member

    Joined:
    Oct 27, 2014
    Messages:
    1,703
    Likes Received:
    240
  7. tcmichals

    tcmichals Member

    Joined:
    Feb 25, 2015
    Messages:
    54
    Likes Received:
    27
    I'm going to push forward and create a gdbserver that runs on the A9 and accesses the debug unit, i.e DHCSR, DEMCR . Basicly do what openOCD and pyOCD do.
    I think the hard part is to work with the kernel module to alloc memory to load the code for the M4, power up/power down M4, and start it.
     
  8. jas-mx

    jas-mx Active Member

    Joined:
    Dec 31, 2013
    Messages:
    407
    Likes Received:
    118
    You need to be aware that the M4 in my opinion is bettered described as a 'slave' core which has a number of ramifications, such as

    1. sharing of clocks between the 2 cores (stopping clocks for one may effect the other).
    2. how/when the M4 can be started or reset. There are assumption in the current kernel that the M4 has to be alive before the kernel boots so that it can control power management and setup shared clocks.
    3. memory map between the cores is different, the M4 vector table may not sit as the obvious location.

    In my opinion if your planning to debug, then JTAG may be the only practical option. Which itself may have restrictions, for example the M4 is only visible to JTAG once the M4 has been enabled from the A9.
     
    Last edited: Jun 26, 2015
  9. tcmichals

    tcmichals Member

    Joined:
    Feb 25, 2015
    Messages:
    54
    Likes Received:
    27
    >There are assumption in the current kernel that the M4 has to be alive before the kernel boots so that it can control power management and setup shared clocks.

    Where is this in the kernel? In mu.c? The current examples in the mqx (RTOS) Linux sends messages to the M4 for low power mode, i.e M4 lis a client.

    I would think the device tree would set all of this up depending if the M4 is running, there are several device trees, with the M4 running and not running.

    > memory map between the cores is different, the M4 vector table may not sit as the obvious location.
    There is a register to map this.

    FYI: There are several examples, with linux creating a TTY interface so M4 and Linux can exchange simple messages... So, that is good.
     

Share This Page