uTasker / uTasker-Kinetis

uTasker V1.4.11 based open source version for Kinetis and STM32 parts
60 stars 35 forks source link

Problem with running STM32Fxx with VS2015. #6

Closed shadowkane closed 5 years ago

shadowkane commented 5 years ago

Hello, before i post my problem i want to mention that i'm new with utasker and STM. my problem is when i try to run the application with STM3241G_EVAL (or any STM32Fxxxx) i get this error "Exception thrown at 0x0048775C in uTaskerOpenSource.exe: 0xC0000005: Access violation writing location 0x00000000". the IDE open the STM32Sim.c file and point to source of the exception which is: if (ucSimulatedFlash >= &ucFLASH[SIZE_OF_FLASH]) { // check flash bounds _EXCEPTION("Attempted access outside of internal Flash bounds!!!"); } " ucSimulatedFlash 0xf85e8940 error reading character of string ".

by the way, the build was ok. and if i test to application with the default configuration which is using "ARDUINO_BLUE_PILL". the interface pops up with no error and the blink led works fine. changing the board lead to the error above. thank you.

uTasker commented 5 years ago

Hi

The problem was with the use of FAT_EMULATION (when the USB is connected it shows up as an emulated hard drive displaying dynamically generated file content according to http://www.utasker.com/docs/uTasker/uTaskerEmulatedFAT.pdf). The problem was that larger Flash devices display more data (and use a section of Flash to store it) and the location is defined in application.c using #define LINEAR_DATA_1 (const unsigned char )(256 1024) // internal flash address of the start of the file's raw data which can be modified to suit, but this is incorrect for the STM32, who's flash starts at 0x8000000.

The correction was to change this to #define LINEAR_DATA_1 (const unsigned char )(FLASH_START_ADDRESS + (256 1024)) // internal flash address of the start of the file's raw data so that it is portable between devices with any Flash starting address

The simulation error was pointing out the fact that an attempt was being made to read from an invalid flash address (which the code was doing incorrectly). If you use the call stack you will see which function is doing it and then corrective measures can be made (as I needed to do). The change is checked in so should now be OK across all larger STM32 devices (without needing to remove the FAT_EMULATION support).

Regards

Mark

shadowkane commented 5 years ago

thank you