This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3358: PRU Support Package Questions

Part Number: AM3358

The PRU_Demo in the support package contains the following snippets  in pru.c

1)

//******************************************************************************
//    PRU ICSS Reset
//      This function resets the PRU cores.
//******************************************************************************
void PRUICSSReset(void)
{

    HWREG(SOC_PRM_PER_REGS + CM_PER_L4LS_CLKSTCTRL) |= 0x2;    /* Reset PRU */  // should be: RM_PER_RSTCTRL
    HWREG(SOC_PRM_PER_REGS + CM_PER_L4LS_CLKSTCTRL) &= 0xFFFFFFFD;

}

Question 1: I would think that the offset should rather be RM_PER_RSTCTRL (refman AM335x  p.1411), since this is related to the PER domain resets, not to clock management.

Since the value of CM_PER_L4LS_CLKSTCTRL is the same as RM_PER_RSTCTRL,namely 0, the difference has no impact.

2)

//******************************************************************************
//    PRU Memory Fill
//      This function takes and a pointer length and value to be placed and
//      iterates through the memory placing the pattern.
//******************************************************************************
void PRUMemFill(unsigned int StartAddress, unsigned int Length, unsigned int  Pattern)
{

    memset((unsigned char*)StartAddress, Pattern, (Length/4));

}

Question 2: why is the nb of bytes to be filled divided by 4 ?.

Thanks

Peter

  • Hi,

    Which SW version are you using? Do you use any SDK (RTOS/Linux), which version?

    Best Regards,
    Yordan
  • Hi Yordan

    I use the latest version of the support package which is 5.4.0. There is no RTOS / Linux involved as the examples (PRU_Demo) don't use a RTOS.

    Thanks

    Peter

  • Hello Peter,

    That code in pru_cape/pru_demo/StarterWare/* is no longer supported since we no longer support StarterWare.

    Are you just trying to get started on PRU? Take a look at the PRU Hands-on Labs for our currently supported getting started material.

    Regards,

    Nick

  • Hi Nick
    Thanks for the pointer. Yes, I have seen these examples, unfortunately they seem a little less comprehensive than then those in the pru support package. In particular, the PRU_Demo project showed how to load a user selectable PRU project image from the running AM335x core.
    This seems to be an interesting and important technique. Also, the original support package contained an Audio example.

    It's good to know that the the Hand-on Labs is now the maintained repo for PRU examples, personnally I would find it helpful if this Lab could contain also some more complex examples, in particular at least one that shows the interaction between the Cortex A8 core and the two PRU cores ( in the case of the AM335x).

    Anyway, thanks for link
    Peter
  • Hello Peter,

    Take a look at Lab 5 for a discussion of using RemoteProc to load PRU firmware (when running Linux on the ARM) and communication between ARM and PRU with RPMsg.

    Hope this helps,
    Nick
  • Hi Nick, I certainly will, however from a "flattening the learning curve" point of view, I feel more confortable to start with
    bare bone experiments via JTAG than with a complex OS layer like Linux on top of an already very complex SOC. One reason
    for this is the debug environment available in CCS that is not available when working under Linux.

    Thanks
    Peter
  • Hello Peter,

    We are actively taking feedback for updating the Labs found in the PRU Software support package - based on customer input in 2018, the latest PRU Software Support Package now has Lab 0 (a hello world style lab that does not have any hardware dependencies), and both Lab 0 and Lab 5 were expanded to all processors that support a PRU (the hardware-specific labs are still designed specifically for a beaglebone black). I will update the Hands-On Lab documentation to cover those changes sometime in 2019.

    So if you have any feedback as you are going through the labs, please let me know!

    Regards,
    Nick
  • Hi Nick
    Thanks, I certainly will.

    For the moment, what keeps me up at night, is the question what strategy to adopt when leveraging the whole SOC, that is - in the case of Beagle Bone Black's AM335x - the Cortex A and the two PRUs. How do I load programs in each core and how can I let them interact. One strategy ( that I am currently testing) is to load three programs into the three cores with the help of Debug Server Scripting.
    The advantage is, that I can have three independent eclipse projects and I can load and test each of those programs - at least those parts that are not communicating with the other cores and that the provisioning code remains external to the program.
    Then PRU_Demo example apparently adopted a different strategy, where the Cortex A8 loads previously compiled image objects into the PRUs, so program deployment is part of the main core. If I correctly understand the example,. this requires modification of the *.cmd file as well ( not sure if this true ...). The advantage here is that code can be "hot" loaded into the PRUs, depending for example on user input.

    As I will try to come up with a demo where all three cores interact, I will certainly reach out to the forum for help since I can't find documentation or examples on how exactly this is done ( of course its specified in ref man, but then an example is worth a thousand pages ...)

    Thanks
    Peter