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.

C6727 UHPI problem



  

 

hi,

I am facing problem with C6727 UHPI communication with  PowerPC based host microprocessor(MPC-8248).

 

 

The configuration of UHPI is single HPIA, multiplexed full word mode with Byte addressing option enabled.

 

 

Sometimes while host tries to program the DSP (DSP is in UHPI boot mode), HRDY signal from DSP is continuously held HIGH for the entire duration of chip select and hence write access is failing. 

This behavior is inconsistent, and sometimes we are not observing any failures and behavior of HRDY signal is as expected.

 

 

We connected the emulator on the target DSP and could observe that sometimes HPIA/HPIAW register address value is going to unknown address range(0xFFFFFFFF or 0xC0000000 etc), this time read or write access looks like going to other address.

Another issue here is after bootloading the DSP code from UHPI, when DSP application code is running, we have observed that, DSP gets hanged in ROM API region after some time. This is observed only during UHPI access from host CPU.

 

 

We are using following ROM API's in our application code for time critical sections:

 

ROM API Address
DSPF_sp_maxval 0x000240E0
DSPF_sp_blk_move 0x000252A0
DSPF_sp_vecsum_sq 0x00024760
DSPF_sp_dotprod 0x00023E60

 Interesting thing is whenever DSP stops due to UHPI access, it halts in ROM API region(Eg: 0x000241A0), and there it will be in an infinite loop.

Please give me some clue about this problem. My queries are:

1. Whether ROM initialization error is causing this problem?

    SPRS 277C (section 2.3.1 Patches to Bootloader/System Initialization), bootloader also need s ROM patch?

    ROM patches are installed in applicatiuon code .

3. What are the possible reasons for UHPI read/write address mismatch or HRDY signal to go HIGH?

Please help me to resolve this issue.

Thanks,

Balachandra

 

 

 

 

 

 

 

 

 

  • So did disabling interrupts around the calls to the ROM functions fix your second issue where it occasionally got "stuck" in the ROM code?

    Can you attach a screenshot of the HPI issue?

  • yes, that was mere escape from the long awaited issue:) I did lot of debugging for around 2 months but couldn't identify the problem. 

    But everything vanished within a day, after the change suggested by you, I am grateful to you for that.

    Coming back to this problem, eventhough we are able to program DSP through UHPI, occasionally programming failure is observed.

    We have observed different failure conditions when UHPI fails. As of now, there are three scenaorios listed as follows:
    
    1. During programming, it fails at the first non-zero value (0x100015F4 - 0xDBEF, all previous locations are 0's in the DSP image). 
    HPI_HREADY pin is continuously HIGH for the duration of chip select. Even after issuing reset and continuing, same situation occurs. 
    Sometimes, after 3-4 retries it recovers and programming succeeds. 
    2. During run time, we have observed once that when CPU writes the HPIA value to DSP, the MSB is lost. This is noticed after connecting the
    emulator. For eg, if CPU writes 0x10000714, it becomes 0x00000714 and CPU reads from this location. 
    3. When CPU tries to read a block of memory locations, HPI_HREADY is continuously held HIGH.  But during this
    scenario, HPIA values are proper (checked by connecting emulator). But after this, when CPU tries to write or read, then HREADY status shows 
    that UHPI is not ready for any access from CPU. 
    
    Please let me know if you need any other information.
    
    
    Thanks,
    Balachandra
    
    
    
    

     

     

     

  • I've had previous issues related to "strange" behavior with HRDY that was caused by electrical issues on the UHPI bus.  Can you post a jpg/png image of the hookup between 6727B and external processor?  I recommend carefully checking the signals on a scope to verify the connection:

    • Monotonic edges, no glitches on the signals (control signals especially)
    • Proper voltage levels
    • Datasheet timings met

    I recommend using an oscilloscope to check the signal integrity and then perhaps a logic analyzer for protocol correctness (e.g. properly observing HRDY, etc.).  I've had scenarios where customers were trying to use ONLY the logic analyzer but the logic analyzer was masking electrical issues since everything just shows up as 1 or 0.  Make sure you use both.

    Brad