What is wrong with this "HAL_UART_Transmit(&UartHandle, (uint8_t*)'\0'

[LMI2]

I am trying to send 0h, that is one byte with 8 zeros. But HAL_UART_Transmit jumps to the error handler.

I am using Keil with 746 Discovery.

I have tried

if(HAL_UART_Transmit(&UartHandle, (uint8_t*)'\0', 1, 5000)!= HAL_OK)
  {
    Error_Handler();   
  }
and
if(HAL_UART_Transmit(&UartHandle, (uint8_t*)0x00, 1, 5000)!= HAL_OK)
  {
    Error_Handler();   
  }
And so on.

Keil is having a bad day and making debugging difficult when code does run in order but this doesn't look like a Keil problem.

[Tesla DeLorean · Accepted solution]

if(HAL_UART_Transmit(&UartHandle, (uint8_t*)"\0", 1, 5000)!= HAL_OK)

[LMI2]

Thank you again. I'll try them later today.

Is this also wrong: HAL_UART_Transmit(&UartHandle, (uint8_t*)0x00,

Why didn't the compiler warn about them.

By the way, this should be:Keil is having a bad day and making debugging difficult when code does NOT run in order but this doesn't look like a Keil problem.

[Tesla DeLorean]

Clearly it is wrong, you are casting a NULL pointer.

The compiler doesn't complain because you explicitly cast the value to what it was looking for as the function parameter.

The compiler does what you tell it to do, what you tell it to do isn't consistent with what you want it to do.​

[AvaTar]

C is not really a simple language.

Constructs with slightly different syntax can have very different semantics.

Re-reading a good tutorial from time to time is no waste.

[LMI2]

Thank you both. (uint8_t*)"\0" helped. Although the IDE acts a very strange way. It does not execute instructions in order, but that's an other post.

To Avatar: "C is not really a simple language." Yes, C is nothing but a pig exception.

[Tesla DeLorean]

The CM7 is a super-scaler pipelined architecture. Multiple non-conflicting instructions execute at once, and optimization can cause apparently non-sequential/out-of-order execution. Remember the C line may compile to multiple assembler instructions, and the granularity of the debugger's understanding of the code is one C line, which may be spread around. There might also be some core level errata related to revision/patch levels, because single stepping is an unnatural state for the core to be operating in.

I rarely use single stepping to understand what my code is doing, I can do static analysis to confirm the logic is correct, and if I want to know what the processor is doing, or likely to do, I read the assembler directly and follow that.