• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 477 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.

HPI control problem

Vladimir Podosinov
Prodigy 150 points
Other Parts Discussed in Thread: TMS320C6455, SN74ALVC162836

Hello,

I am interfacing an ADC to the HPI bus on the TMS320C6455. I know that HPI is a slave peripheral, and that actually makes a lot of trouble for me, but unfortunately there is no other choice for parallel ADC as EMIF is already taken by other device. ADC provides it's own clock (40 MHz), so I use that as strobe. 20 bit output is just mapped to the data pins. I always write to the HPI, so write pin is set low, and HCS set high. HPI control pins are controlled from peripheral connector using DC_1 and DC_2 bits. Now here is my question:

I am able to set an address to write to, but here is the problem. HPIC is set to whatever the default values at reset are (which is all 0), so when I just start the board for the first time, and run the program I can write address to both HPIAW and HPIAR (As DUAL Address disabled), and when I look in the memory map, I even see values have been written. However, when I reload the program (that is, no turn on/off operation) I can only see the write operation being done to HPIAR, also there are no more new values in the memory. In fact, if I just keep running the program (infinite while loop) without reloading, I never see memory change.

What is the issue? Do I need to perform reset or something like that every time I write to HPID. I am using no autoincrementing, yet I see more then one memory location have been written.

I read all the documentation for the HPI, and it seems like I am doing everything right, yet I do not see good results. Also, I am writing to DDR2, that is below 0xE0000000 memory address. I am trying to avoid adding a lot of control hardware.

Thanks, Vladimir

  • 0
    TI__Guru* 84110 points

    This is by far one of the cleverest plans I have seen. This is very ingenious and sounds very simple and straight-forward to do. Unfortunately, it is not going to be this simple.

    The issue is that the HPI was not designed to work this way. And the more amazing thing is that you have seen any results at all of memory locations changing.

    I am sure you have reviewed the operation of the HPI in the HPI User's Guide SPRU969b. There are numerous issues that have to be resolved, but the easiest to point out is that HPIAR and HPIAW are shown on page 42 to be read-only for accesses from the CPU. The DSP should not be able to write to these registers to set the target address.

    So, to stay on the HPI, you will have to inject correct values as needed for the HPIC and HPIAR/W registers. This could be done with a small FPGA or CPLD with enough pins, or a three-state buffer like a 244 plus pull-up/pull-downs if the same value can work for both the HPIC and HPIAR/W registers, plus some extra GPIOs, maybe. The SN74ALVC162836 might be a good choice of a device that could give you the three-state control, unless of course your ADC has three-state control that would avoid this requirement.

    That could also be a fun plan to try, but there might still be issues with a free-running ADC writing to the HPI every 25 ns. If you are not intelligently monitoring HRDY, then there could be FIFO overruns and data losses. Plus, that is a lot of data to operate on unless all you want to do is sample it for a while then stop.

    The EMIF is the right place for this, but even there you would have to add logic to hold the value until it gets read, unless you can guarantee catching it at the right time. The SN74ALVC162836 might be a good choice of a device that can latch the value on your clock edge then let the DSP read it by EDMA through the EMIF using an available Chip Select.

  • 0 in reply to RandyP
    Prodigy 150 points

    Thanks. I appreciate for the input. I will look into the solution for the tri-state buffer. I know how wierd it is to use something it's not designed for, but for now I am going with what I have. Writing an address was definately a hassle, and I had to use pretty much a random address, within applicable space. I used dip switches for that, but I think I will need to use CPLD in the end to have a better control and some buffering. Thanks.