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.

IWR1843BOOST: IWR1843BOOST

Part Number: IWR1843BOOST

Hi,

can I access the GPIO pins directly in DSS?

The docs tell me about their use in MSS (as per oob demo) - the dubugger says the registers are memory mapped, so does this mean I can access then via DSS space as well as MSS?  I'm only interested in reading the level on GPIO1, as this is all the BOOST allows easy physical access to.

I've added GPIO1 to MSS, and can see the level change using the debugger, so I've got pinmux & general set-up OK.

thanks

Alan Milne

  • Alan,

    Can you please tell me exactly which registers you are looking at ?

    Thanks,

    Angie

  • Hi Angie,

    in CCS debug, select MSS, and look at REGISTERS window: GIO and thereby GIODINA.  I can see value 0x4 (yellow LED lit,  GPIO_2) and then 0x6 with the GPIO_1 button on the BOOST pressed i.e. input value 1.

    GPIO_1 is the only easy-to-access line on the BOOST, but the processing where I need to use it is, of course, on DSS.  I'm hoping there is a way to get at it in DSS, as I don't have many other options - the code might run in MSS, but I don't think that's how I'm supposed to use the device!

    thanks

    Alan

  • Hi Alan,

    The GPIOs are usually only accessed by the MSS (please refer to the Technical Reference Manual on the product folder page). However, if you can pinpoint the exact memory location on the MSS side and translate the address to the DSS address scheme you can access the registers. This is not something we have any documentation on but I can share this example code written on DSS:

    volatile uint32_t *gpioPortAWr = (uint32_t*)0x05F7BC40;/* GIOSETA */
    volatile uint32_t *gpioPortAClr = (uint32_t*)0x05F7BC44;/* GIOCLRA */
    
    
    volatile void Troggle_GPIO2(uint16_t times)
    {
    volatile uint16_t cnti;
    
    for(cnti=0;cnti<times;cnti++)
    {
    /* Set GPIO status to high */
    *gpioPortAWr = (1<<2);
    /* clear or set GPIO status to low */
    *gpioPortAClr = (1<<2);
    
    }
    }

    Thanks,

    Angie

  • Hi Angie,

    exactly the sort of information I was after - many thanks.

    I must admit, thinking (and learning) more about it, I may be better off putting at least some of my code in MSS ... I've avoided this so far (other than extending the CLI to add my own controls etc) , as it's not the truly DSP processor, and it has more to do with the operating system than DSS, and I don't want to risk mods that upset things I don't fully understand yet.

    What I really want to do is trigger sampling from an external source.  Rather than trying to get DSS to record the samples when I want, it may be a better approach to let DSS follow MSS/BSS (as I believe the oob demo does, via waiting for chirpAvailable interrupts), and add the timing controls in MSS ... somehow.  This may be something along the lines off setting CONTINUOS_MODE on GPIO_1 rising edge, then clear it after a given number of samples.

    More "investigative design work" required, especially as I'm trying to use the device outside what it's originally intended for.  I'll leave this open in case you've got any more to add, otherwise you've answered this particular question i.e. GPIO & DSS.

    many thanks

    Alan

  • Hi Alan,

    Anytime!

    I would recommend having some processing on the MSS and some on the DSS as many of our labs do. The DSP is great for signal processing but debugging and development will always be easier on the MSS.

    For now I am going to close this thread since we need to keep each thread limited to one topic. Please feel free to make a new thread for any new topics and link it back to this thread for context. 

    Thank you,

    Angie