• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 256 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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

Alan Milne
Intellectual 285 points
Part Number: IWR1843BOOST


Hi,

this is question about how to correctly implement something in the TIROS/MSS/DSS environment. It may be that I'm actually asking two things - happy to re-do as a further question if you think it fits better.

My starting point is the oob demo code.

What I want to do is add an external trigger - using GFPIO_1 for instance. I'm thinking of doing this by using a WHILE() structure in MSS, which loops round and reads the GPIO. When found, it can start some functionality (possibly continuous mode ... any details of what it starts would be a different question). It will then stop the function after, say, a given number of ADC samples are collected.  The sync signal is external, and completely asynchronous to the 1843.  To avoid (possibly quite variable) service response times, I don't want to use an interrupt, hence thinking of a continuously running loop.

The potentially second question is: the counter may well be on DSS. To minimise run-time delays, I don't want to have to copy values between locations - I'd like a way of the same memory location being accessible in both DSS & MSS. Maybe this is already possible via the two processors having different address spaces, but actually looking at the same memory (e.g. radarCube seems to be visible in both MSS & DSS). I just want to be sure I don't produce any access conflicts.

What would be the best way of adding this:

> is there already a suitable WHILE in MSS which I could add to (without breaking the exiting code)?

> should I e.g. create a new TASK to run this bit, so that it can halt inside the WHILE, but without stalling the whole system?

>  would an interrupt format be better?

> some other method that I don't know about.

many thanks

  • 0
    TI__Mastermind 21801 points

    Hi,

    You may wish to create a new task for this purpose as this will allow you to halt execution in the WHILE, as you mentioned, and will also allow you to adjust the priority relative to the other tasks if needed.I don't think we have any example code which does this but let me confirm and get back to you.

    To your other point,

    Alan Milne said:
    Maybe this is already possible via the two processors having different address spaces, but actually looking at the same memory (e.g. radarCube seems to be visible in both MSS & DSS)

    It is indeed possible to access L3 Ram from both the MSS and DSS. You can find more information such as the specific start address for the shared memory as seen from both the MSS and DSS in the Memory Map section of the TRM (swru522e). Additionally, there is a function which can be used to translate the address from one domain to the other:  SOC_translateAddress().

    Best Regards,

    Josh

  • 0 in reply to Josh Dye
    Intellectual 285 points

    Hi Josh,

    thanks - just what I was looking for!

    On memory access (and maybe 522e answers all this), I'm already accessing L3 in both MSS & DSS, so I guess I'd answered my own question, even if I didn't realised it in this context.

    Just to complete this - my code reads/write L3 at different times, so there's no access conflict.  I'm thinking of where I might say write in DSS, and MSS may try to read the same location at the same time.  As I may only write once, the information might get lost. How is this arbitrated?

    Incidentally, I think, as I'm learning more about the device, I'm going to make a change to how I'm doing things.  I've concentrated in DSS so far.  However, it's now looking like it would be architecturally better to shift ALL of the sample acquisition into MSS. The GPIO comes in there, I can add my WHILE to synchrosise, I can access L3 etc etc - and then carry on processing in DSS, but assuring no access conflicts via different parts of the DSP happening at different times.

    many thanks

    Alan

  • 0 in reply to Alan Milne
    TI__Mastermind 21801 points

    Hi Alan,

    Alan Milne said:
    I'm thinking of where I might say write in DSS, and MSS may try to read the same location at the same time.  As I may only write once, the information might get lost.

    Can you clarify this. In what context would this occur? 

    Best Regards,

    Josh

  • 0 in reply to Josh Dye
    Intellectual 285 points

    Hi Josh,

    assuming that MSS & DSS should be considered as essentially asynchronous to each other, then my DSS code may write a flag value for MSS to read.  However, what if MSS wanted access to that memory at that exact same moment? In which case, DSS might be denied access, and the new flag wouldn't be passed across, and potentially DSS wouldn't know.  I know there are semaphores & mail boxes etc, but I'm looking to find the minimum code solution - and with minimum latency.

    522e section 2.2.1 does talk about arbitration ... and of L3 being accessible by both processors.

    Slightly aside, but still on L3 - 522e says its 2Mbits - but I sure at least one other doc says its only 1Mbit, and that's how the CCS projects (oob demo etc) are set up.  Which is correct?

    many thanks

    Alan

  • 0 in reply to Alan Milne
    TI__Mastermind 21801 points

    Hi Alan,

    Sorry about the delay here. For the purpose of communication and / or data transfer between the MSS and DSS subsystems, mailbox or HSRAM are recommended. Please find the relevant documentation in sections 18 and 11 of the TRM (swru522e).

    On L3 memory, the size is 1MB, of which 768KB is accessible as shared memory and 256KB is reserved. Refer to section 10.2 of the TRM. Please allow me to confirm internally on the meaning of 2MB shown in the other section of the TRM or if it is a mistake.


    Best Regards,

    Josh