STM32F722IEK6 processor not counting properly

[Brian D]

Posted on April 21, 2018 at 02:41

The original post was too long to process during our migration. Please click on the attachment to read the original post.

[T J]

Posted on April 21, 2018 at 03:11

this works

unsigned char SPI_t::transfer_receive(unsigned short data) {

    char RxSPI;

 //   Clear_SPI1_nSS_Out();

    while (!(hspi1.Instance->SR  & SPI_FLAG_TXE))

        ; // make sure we are ready

    while ((hspi1.Instance->SR  & SPI_FLAG_RXNE))

        RxSPI = hspi1.Instance->DR;  //clear out / read all the bytes left in the Rx register

    *((__IO uint8_t *)&hspi1.Instance->DR) = data;                // force the SPI to transceive 8 bit

    while (!(hspi1.Instance->SR  & SPI_FLAG_TXE))

        ;      //wait for buffer to start shifting

    while ((hspi1.Instance->SR  & SPI_FLAG_BSY))

        ;     // wait for all bits to completely leave the chip

    while ((hspi1.Instance->SR  & SPI_FLAG_RXNE))

        RxSPI = hspi1.Instance->DR;  //read all the bytes left in the Rx register, the last one is for your reading.

 //   Set_SPI1_nSS_Out();               

    return RxSPI;

}

[Brian D]

Posted on April 21, 2018 at 04:12

TJ,

I don't have question for SPI -- it works fine.

My question is about the spi non-related delay loop: 

for(n=0; n<1500; n++); that it took too long but I don't know what had caused the problem.

Brian

[T J]

Posted on April 21, 2018 at 05:37

I guess you already know that it is bad practice to use a counter delay like that.

that's why they installed timers in the first place, to be processor clock/cache/wait variable type, etc. independent.

a float would count much slower than an int.

[Brian D]

Posted on April 21, 2018 at 07:20

This is just a simple test code to emulate a camera controlling the lens via a sort of SPI bus. The delay counting loop is a quick way for the test; without any interrupts the countering loop should be precise. No floating here; just unsigned int. I'd like to know where to look for the cause of this behavior.

Brian

[Joerg Wagner]

Posted on April 21, 2018 at 22:58

Instruction cache enabled?

[Brian D]

Posted on April 22, 2018 at 00:41

Hi Joerg, I just installed Eclipse IDE package recently and so it is currently set to default. But I will look for the effects of instruction catch enabled.

.

[Brian D]

Posted on April 23, 2018 at 22:43

This problem appeared with the chip ran under debug mode, and so today I thought might be it would be fine if I flash the chip with release configuration. After generated the .elf in the release folder, I went to target > program chip > but the tool does not provide the option to choose the release folder; only the debug folder is available. My co-worker has both the release and debug folders under target > program chip. Anyone know why I don't have the release folder?

[Tesla DeLorean]

Posted on April 23, 2018 at 22:53

You'll need to get familiar with the tool chain you have chosen and the multitude of settings in configuration, installation and metadata, that control what, where and how things are built.

If the project description file is in XML I suppose you could use a diff or merge tools to observe the differences between the two system.

Keil has option tabs controlling what directories output is directed too.

[Brian D]

Posted on April 24, 2018 at 03:34

OK, I think here is the reason why the for() loop counter is so unpredictable. It seems the compiler might optimize or ignore a dummy loop as the for(n=0; n< 500; n++); 

So I changed it to

for(n=0; n<100; n++)    Temp = SPI2.DR;      // read SPI2 data register (assuming 100X read would have the same delay as wished. This forced the tool not to ignore or did funny thing with the loop, and I got the consistence counting delay.

So the lesson learned is do not use an empty for() loop for delay -- it is unreliable. 

Thank you all for trying to help.