Double preprocessor variable for power pin

[Jwf68]

I am trying to use the libary for an STM32 MCU. After stepping the SPI initialization code, I discovered that there are two preprocessor variables for the power pin.
EVE_PD_PORT_NUM=4U mening GPIOD
EVE_PDN_PORT_NUM=4U mening GPIOD
This appears to be wrong.

[RudolphRiedel]

Thank you, I just fixed it.
That was supposed to be EVE_PD_PORT_NUM in EVE_target.c as well.

I left behind STM32 a bit frustrated back then, after I could not figure out how to to use the updated DMA unit of the STM32H7.

[Jwf68]

A different problem that I have. STM32 example load image is stuck in a loop, EVE_busy() does not return zero. Would you consider helping via remote meeting with Teams? This is a commercial project, so we can pay for support.

[RudolphRiedel]

I am making it a (maybe bad) habbit of not getting paid for support here.
And I have never used teams on my personal Windows machine, I am not even sure that it can be working since I am trying to avoid using a microsoft account.
Apart from that, don't trust my STM32 skills, I never used this for anything beyond tinkering with SPI. :)

That said, which STM32 are we even talking about?
There is a small chance, but maybe I have an eval board that at least is close enough.

Not returning from a load image sounds like an issue with the image though, if you can get up to that point everything else must be working already.
What are the specs of that image, format and binary size?

[RudolphRiedel]

Ok, I just dusted off my STM32F407 Discovery and copied over the latest library files to the STM32CubeIDE project I was using.
It still builds and it still runs, including one:
EVE_cmd_loadimage(MEM_PIC1, EVE_OPT_NODL, pic, sizeof(pic));

But that image is a .jpg and only 3391 bytes in length.

Edit:
I took Ducati_side_shadow.png from the EAB "Image Utility Test" folder.
It is 75628 bytes and is 288x163 pixels.
Putting this line first:
EVE_cmd_loadimage(0, EVE_OPT_NODL, ducati, sizeof(ducati));
The image is loaded fine and I am displaying it right now.

And I put it first because cmd_loadimage is using the top 42kiB of memory to decode .png files.

[Jwf68]

I am using a STM32F405RGT6 bare bone no operating system.
Display with FT812 https://www.mouser.se/datasheet/2/880/DS_ME812A-WH50R-1154864.pdf
I have an C++ program that does hal initialization but the SPI and power pin config is your code. I have got https://github.com/Bridgetek/EVE-MCU-BRT_AN_025 to run this way, so the hardware is ok.

I have modified your main.c from https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/examples/EVE_Test_STM32_RiTFT50_PlatformIO/src
so that I can call it from my C++ code.

In tft.c the program never returns from:
EVE_cmd_loadimage(MEM_PIC1, EVE_OPT_NODL, pic, sizeof(pic));

In EVE_commands.c
uint8_t EVE_busy(void)
Never returns zero.
Return variable ret is set to 13 in: ret = EVE_FIFO_HALF_EMPTY;

Any Idea what the problem is?

I can not use the preprocessor variable USE_HAL_DRIVER since my application does not compile, if it is defined.

Settings:
Not possible gives compile errors USE_HAL_DRIVER
STM32F4
EVE_ME812A
EVE_SPI_NUM=3U
EVE_SPI_PORT_NUM=3U
EVE_SPI_GPIO_ALT_FUNCTION=GPIO_AF6_SPI3
EVE_SCK=GPIO_PIN_10
EVE_MISO=GPIO_PIN_11
EVE_MOSI=GPIO_PIN_12
EVE_SPI_PRESCALER=SPI_BAUDRATEPRESCALER_128
EVE_CS_PORT_NUM=1U
EVE_CS=GPIO_PIN_15
EVE_PDN_PORT_NUM=4U
EVE_PD_PORT_NUM=4U
EVE_PD=GPIO_PIN_2 STM32F405xx
EVE_DMA

[RudolphRiedel]

Ah interesting, the F407 that I am using is practically the same.
And my settings are very similar, except for:
EVE_SPI_PRESCALER=SPI_BAUDRATEPRESCALER_128

That seems to be rather low for the SPI clock.
I am using
EVE_SPI_PRESCALER=SPI_BAUDRATEPRESCALER_4

I renamed USE_HAL_DRIVER to USE_HAL_DRIVER! and it had no effect at all.
I am not sure why this was set.

But, I am using an EVE3-50G right now, so a BT815.
And somehow my EVE2-50G with FT813 is not working anymore.
Using the BT815 as if it were a FT813 should also work - but it does not.

Looks like I might have broken FT81x support somehow.

[RudolphRiedel]

Try this in EVE_commands.c:
void EVE_cmdWrite(uint8_t const command, uint8_t const parameter)
{
EVE_cs_set();
spi_transmit(command);
spi_transmit(parameter);
spi_transmit(DUMMY_BYTE);
EVE_cs_clear();
EVE_cs_clear(); // <- extra line
}

I have no idea yet why this happens, but the first sequence I am seeing without this line for FT813 is this:

But these are two commands so this is supposed to look like this:

I have no idea how this is possible.
If this would be an issue with the controller optimizing something away, it also should not work with the BT815.

#if defined (EVE_HAS_CRYSTAL)
EVE_cmdWrite(EVE_CLKEXT, 0U); /* setup EVE for external clock /
#else
EVE_cmdWrite(EVE_CLKINT, 0U); / setup EVE for internal clock */
#endif

#if EVE_GEN > 2
EVE_cmdWrite(EVE_CLKSEL, 0x86U); /* set clock to 72 MHz /
#endif
EVE_cmdWrite(EVE_ACTIVE, 0U); / start EVE */

So in the two cases I am looking at, it either is
EVE_cmdWrite(EVE_CLKINT, 0U); /* setup EVE for internal clock /
EVE_cmdWrite(EVE_ACTIVE, 0U); / start EVE /
or
EVE_cmdWrite(EVE_CLKEXT, 0U); / setup EVE for external clock /
EVE_cmdWrite(EVE_CLKSEL, 0x86U); / set clock to 72 MHz /
EVE_cmdWrite(EVE_ACTIVE, 0U); / start EVE */

Why the heck is the first not working properly, but the second is?

And using
EVE_cmdWrite(EVE_CLKINT, 0U); /* setup EVE for internal clock /
EVE_cmdWrite(EVE_ACTIVE, 0U); / start EVE /
EVE_cmdWrite(EVE_ACTIVE, 0U); / start EVE */
Also works:

[RudolphRiedel]

Adding a NOP in EVE_cs_clear() also works:
static inline void EVE_cs_clear(void)
{
while (LL_SPI_IsActiveFlag_BSY(EVE_SPI)) {}
LL_GPIO_SetOutputPin(EVE_CS_PORT, EVE_CS);
asm volatile ("nop"); // test!
}

But why though?
With the NOP and two commands CS is only high for 40ns.
Without the NOP and three commands CS is high for 80ns.

Is this some weird cache issue with the STM32F40x?

[Jwf68]

You have used a mix of two STM32 libarys, HAL library and LL library. Atached files only use the HAL library.
EVE_MCU_STM32cube.zip
Chip select NOP commented out in
https://github.com/Bridgetek/EVE-MCU-BRT_AN_025/blob/main/ports/eve_arch_stm32/EVE_MCU_STM32.c

[RudolphRrr]

You have used a mix of two STM32 libarys, HAL library and LL library.

Yes, this is by design, the HAL library is significantly slower.
Well, this applies to the SPI transfers and checking of the flags, I guess setting the I/Os might not be that bad.

That might also explain why you have issues with the HAL settings, I setup my project to use LL.

Atached files only use the HAL library.

Thank you, I'll play with this later.

[Jwf68]

"That might also explain why you have issues with the HAL settings, I setup my project to use LL."
In https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/examples/EVE_Test_STM32_RiTFT50_PlatformIO/src/main.c
I have found HAL_Init(). HAL_Init() is called in C++ app main method.
What do you do to init the LL library?
All that I have done is copying stm32f4xx_ll_spi c and h.
We are using GCC and Visual sudio with visualGDB.
Cand you please chare your complete STM32CubeIDE project?

[Jwf68]

From https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/src/EVE_target.c
/* SPIx GPIO Configuration: */
gpio_init.Pin = EVE_SCK|EVE_MOSI|EVE_MISO;
gpio_init.Mode = GPIO_MODE_AF_PP;
gpio_init.Pull = GPIO_NOPULL;
gpio_init.Speed = GPIO_SPEED_FREQ_HIGH;
gpio_init.Alternate = EVE_SPI_GPIO_ALT_FUNCTION;
HAL_GPIO_Init(EVE_SPI_PORT, &gpio_init);

I generated code for the low leval hal using the STM32CubeMX:
GPIO_InitStruct.Pin = LL_GPIO_PIN_10|LL_GPIO_PIN_11|LL_GPIO_PIN_12;
GPIO_InitStruct.Mode = LL_GPIO_MODE_ALTERNATE;
GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_VERY_HIGH;
GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_PUSHPULL;
GPIO_InitStruct.Pull = LL_GPIO_PULL_NO;
GPIO_InitStruct.Alternate = LL_GPIO_AF_6;
LL_GPIO_Init(GPIOC, &GPIO_InitStruct);

You are using spi low level liabary, but init is done using HAL libary.
Can this realy work?

[RudolphRiedel]

Ok, I tried this now:
static inline void EVE_cs_clear(void)
{
while (LL_SPI_IsActiveFlag_BSY(EVE_SPI)) {}
// LL_GPIO_SetOutputPin(EVE_CS_PORT, EVE_CS);
HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_SET);
}

static inline void EVE_cs_set(void)
{
// LL_GPIO_ResetOutputPin(EVE_CS_PORT, EVE_CS);
HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_RESET);
}

And the impact is measureable, but not at all significant.
The host commands are a few % slower and all the other non-DMA commands execute a little slower as well.

For example, the three read commands I am using in my touch function now need 300ns to 400ns longer with HAL than with LL, that is not enough to even try and measure it more acurately.

Well, it works this way while using LL should be working, but somehow does not work reliably as if a call is optimized away but not always...
As using LL is practically using direct register access and the register are volatile, this should never be "optimized" - yet here we are.

One might think that the issue could be that the core is so fast that the IO block has no time to actually carry out the level change before the register is written again.
But that does not explain why calling the function two times does not work and when calling it three times it works.

You are using spi low level liabary, but init is done using HAL libary.
Can this realy work?

Yes, absolutely.
First of all I was wrong earlier, I did not "setup my project to use LL".
There is nothing to set up there, LL does not require initialization, at least not of the library itself.

__STATIC_INLINE void LL_GPIO_SetOutputPin(GPIO_TypeDef *GPIOx, uint32_t PinMask)
{
WRITE_REG(GPIOx->BSRR, PinMask);
}

This is just direct register access with a minimal abstraction so that it can work across most STM32 families as long as the correct include is loaded.

IOPorts are a bad example in this, these are too simple.

void HAL_GPIO_WritePin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin, GPIO_PinState PinState)
{
/* Check the parameters */
assert_param(IS_GPIO_PIN(GPIO_Pin));
assert_param(IS_GPIO_PIN_ACTION(PinState));

if(PinState != GPIO_PIN_RESET)
{
GPIOx->BSRR = GPIO_Pin;
}
else
{
GPIOx->BSRR = (uint32_t)GPIO_Pin << 16U;
}
}

So also almost direct register access.
But as a function that gets called and with an if statement, this needs a few extra clock cycles.

while (!LL_SPI_IsActiveFlag_TXE(EVE_SPI)) {}

This works across a lot of STM32 familes, wherever that bit actually is placed.

ST unfortunately broke with this for the STM32H7 for example:
while (!LL_SPI_IsActiveFlag_TXP(EVE_SPI)) {}

Whatever the reason was behind renaming that bit for STM32H7 only...

Cand you please chare your complete STM32CubeIDE project?

Sure, here:
EVE_Test_STM32F407.zip

Not that this is a real project, just something I tinkered with to implement STM32 support in my library.
I am using the code generator for SPI and GPIO, but I am not even calling the resulting code,
this is just for reference what it might should look like.

And I am using HAL for the initialization as this part is not time crititcal at all.
It does not really matter how long HAL_SPI_Init() needs to jump thru whatever hoops deemed necessary,
it only is called once.

But for example HAL_SPI_TransmitReceive() is 241 lines long for the STM32F4 and does a lot of things that really are not necessary to do over and over and over again.
Like checking if the SPI unit is even active.
Duh, I want to send several thousand bytes per minute over the SPI, not read three bytes from an ADC every now and then. :)

[RudolphRiedel]

This is the software, running on an EVE2-50G from Matrix Orbital, so the chip is a FT813.