When I change a floating-point value to an integer inside a function, the program doesn't execute

[TanTianLong]

When I used S32DS.ARM.2.2 software to compile the project, I had a problem. When I changed an integer value to a floating-point type inside a function, such as 20 to 20.0, the compiled map file had some more link content, and the program ran normally, but when I changed 20.0 to 20, it did not run normally. The program did not enter initialization.

Products:FS32K144HAT0MLLT

When I changed 20 to 20.0, the program ran normally, but the program could not enter the initialization with the value 20, and the app would stop at DefaultISR (in debug mode) after jumping from bootloader to this appWhen I change 20 to 20.0, the map file has a few more library linksbootloader jumps to app and enters DefaultISR

[jiri_kral]

Hi, 

which types are bat1 and bat3? They are float? If So, it is nonsense use abs function. abs() accepts integers and return integer as well. Also is nonsense compare floats like if (bat1 == 0) - if bat1 is float. 

[TanTianLong]

Hi, @jiri_kral 

Did you see my response?

[jiri_kral]

Hi, 

I tried reproduce it on my side, but no success. Do you know which exact instruction in disassembly invoke the exception? Because it doesn't make sense at all. 

I'm suspecting that if you put float instead of int, the comparison between int and float makes that the function return 0 (I'm not sure if the return 0 is the correct or return 1 is the correct. Typically return 0 means no error. 

You can also implement fault handler to figure out what exactly happens - https://community.nxp.com/t5/S32K-Knowledge-Base/Fault-handling-on-S32K14x/ta-p/1114447 

[TanTianLong]

Do you mean the “Disassembly”？

[jiri_kral]

Hi, 

in Debug session you can switch into single instruction mode

and you can step by one instruction in disassembly window (the window appears when single instruction step is enabled) to find out which exact instruction invoke the exception: 

[TanTianLong]

The failed program cannot be debugged single-step, and once you enter the program, you enter DefaultISR

[TanTianLong]

No,they are uint16_t

[TanTianLong]

The problem I've found so far is the 64-bit arithmetic. I defined 64-bit local variables inside a function and did all the arithmetic, including division. When I changed the variable to 32 bits, the program worked. This is where another problem I found earlier is to comment out the 64-bit arithmetic inside the function. So far, the accuracy of the algorithm has dropped, but the program is working. But I don't know why that decimal point makes this 64-bit operation work.

I targeted this 64-bit operation because: I mentioned in the previous diagram that the program doesn't run, it stops at DefaultISR, WDOG_EWM_IRQHandler is displayed, and on the next line is __aeabi_uldivmod, which is a function (presumably added by the compiler) that performs division and modulo on long unsigned integers, with only one place in the program where 64-bit arithmetic is used. So I've targeted the problem here. In practice, this action does have an effect on the program. I couldn't find a good explanation for the effect of floating-point on 64-bit operations