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.

LAUNCHXL-F280049C: GPIO toggle maximum speed F280049, code in RAM

Part Number: LAUNCHXL-F280049C

Hi,

 

I am toggling a GPIO constantly and trying to see the rate at which instructions are executed. The CPU is configured to run at 100Mhz (example from led blinky, (external crystal 20Mhz X 10)/2 = 100Mhz)

The code is as follows:

The assembly listing is as follows:

 

But I see the pin changing state at ~69ns. The OR instruction should execute in 1 cycle and the CPU is executing from RAM. Why isn’t the pin toggling at a faster rate since the CPU is running at 100Mhz.

Even though there would be some propagation delay due to the GPIO being on a  different interconnect, why is the delay as high as 69ns

 

 

 

Thank you

Royston

 

 

  • Hi Royston,

    The C28x has an 8-stage protected pipeline. In order to perform an OR operation, the CPU has to read the data, OR the value, and then write the data back to memory. Because you have multiple ORs back-to-back to the same memory location, this will stall the pipeline. This is because it is protected.

    I believe you may be able to toggle it faster if you did a strict Write operation to register. This would be a MOV instruction.

    You should be able to write C code to compile to the MOV operation relatively easily. You can use the HWREG macro we provide in driverlib in hw_types.h to do this. Also, the addresses will be available in the hw_gpio.h header file.


    #define HWREG(x) \
    (*((volatile uint32_t *)(x)))

    #define HWREGH(x) \
    (*((volatile uint16_t *)(x)))

    For example (this is not exact)
    HWREG(GPIOA_DAT_ADDRESS) = 0x00000004;

    Regards,
    sal
  • Thank you Sal,

    I tried the below as suggested

    and got the CPU to excute the instruction in 20ns. I would guess the 10ns extra delay would be due to the GPIO being on a different interconnect block.

    Thank you

    Royston

  • Hi Royston,

    Yes, that makes sense still. With 20ns, you are looking at a 1-cycle stall. This may be coming from the data write bus or from the program read fetch. I don't think it is due to the protected pipeline anymore.

    sal