• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 480 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.

Strange PASM/PRU behavior

Seth Dziengeleski
Intellectual 325 points
Other Parts Discussed in Thread: OMAP-L138

I'm trying to write some code for the PRU in the OMAP-L138 using PASM, and I've run into some odd troubles.  I think either the assembler or the hardware has a bug.

 

I have a u8, global.flags, set to 0x04.  I'm trying to set bit 1, which would make it 0x06, then store it to memory.  Because of my troubles, I boiled it down to two sequential instructions:

 

      SET   global.flags, 1

      SBBO  global.flags, config.dest, 0, 1

 

This code results in 0x04 stored in the memory location pointed to by config.dest (a u32).  NOT my intended result!  However,

 

      SET   global.flags, 0

      SBBO  global.flags, config.dest, 0, 1

 

results in 0x05, and

 

      SET   global.flags, 3

      SBBO  global.flags, config.dest, 0, 1

 

results in 0x0C.  Both of these results act as expected simply using different constants.  Furthermore, I can get my desired result with a workaround:

 

      LDI   tmp.i, 1                      // loads my desired bit into a u8 register

      SET   global.flags, tmp.i

      SBBO  global.flags, config.dest, 0, 1

 

It clearly looks as if I can't set a bit using an immediate 1, but I can set it using a 1 stored in another register or any other bit with a different immediate value.  I saw a similar behavior earlier using the ADD instruction, only that time the immediate that failed to work was 0x10.  Are there any known errata for the PRU or PASM that might explain this behavior?  I'm running the Windows version 0.70 of pasm.exe on Windows 7.

  • 0
    TI__Prodigy 10 points

    This is unusual. I have not seen any behavior like this in the past.

    I think the first step is to generate a program listing and check the opcode that is being generated for the source line(s) in question. You can do this by adding a '-L' to your command line when you assemble the file. If you post the portion of the listing here containing those instructions, I can disassemble the opcodes and make sure they look ok. (If the assembler doesn't take '-L', you can use a lowercase 'l'. The former generates an annotated source code listing while the latter is more of an internal format listing (after pre-processing)).