Skip to main content
Visitor II
April 27, 2019
Solved

Instruction timing changing with memory location?

  • April 27, 2019
  • 4 replies
  • 1096 views

Hi. I am writing very time sensitive code on the STM8 mostly using assembly. However, I have noticed that sometimes adding one cycle of delay at one point in the code changing the timing of the whole code. I will explain in more detail to clarify. I have an interrupt which fires based on the a GPIO. I start reading the inputs. My code works, data read is good. I respond, but the timing is slightly off. So I add in a couple of nop cycles to fix it. The read is now broken. Keep in mind this is all a single sequential file of assembly to handle the interrupt. The processor is always in the WFI state when the interrupt fires. But somehow adding a couple of nops somewhere in the code causes everything to break (in terms of timing). I sure there is some explanation for this, but I have yet to find anything in any of the documentation. Any insight would be greatly appreciated.

Thank you,

Chris

    This topic has been closed for replies.
    Best answer by Cristian Gyorgy

    The following snip is from the STM8 programming manual, pg. 22, Doc ID 13590 Rev 3:

    0690X000008B7hbQAC.png

    4 replies

    Visitor II
    April 29, 2019

    Try posting your code (the relevant part of it). It would help us understand what you talk about.

    Chris KAuthor
    Visitor II
    April 30, 2019

    I can't post the exact code but I will try to create something representative which will illustrate the behaviour I am seeing. In the mean time though I just want to clarify if there are any alignment requirements for this device. Do misasligned data or function accesses cause stalls in the pipeline or elsewhere in the architecture? Because I have not been able to find anything in the document alluding that it may be the case. Thanks.

    Visitor II
    April 30, 2019

    The following snip is from the STM8 programming manual, pg. 22, Doc ID 13590 Rev 3:

    0690X000008B7hbQAC.png

    Chris KAuthor
    Visitor II
    May 3, 2019

    That explains it. Thank you.