|
Re: Does FORTE run on systems without OS [message #1747035 is a reply to message #1746839] |
Tue, 08 November 2016 17:25 |
|
Hi
the short answer is in principle yes.
The long answer is that in that case you need to implement interrupt code managing timers communication and other hardware interrupt and feed it into the execution of FORTE. In the start-up code for your µC you would need to create your device and then manage the execution of the CThread classes. For that you can applied different schemes. The simplest which we tried in a bachelor thesis was to use a cooperative scheduling approach. For a device with maybe one or two resources this should be pretty efficient. Unfortunately the resulting code was not nice enough to make it available.
But I'm happy to support you and and according means also to the public repository. I'm also available for a talk in skype or google hangouts if you like.
BR,
Alois
|
|
|
|
Re: Does FORTE run on systems without OS [message #1747358 is a reply to message #1747331] |
Sun, 13 November 2016 17:04 |
|
Dear Lothar,
unfortunately we curently have not much documentation available on this part of FORTE. I think I updated some parts when we reworked code for the last platforms we ported FORTE to. The best starting point would be the the rcX branch in our git repo. There we did several cleanups and improvemnts further reducing the porting effort. The code of interest for your endveors would be to look in one of the src/arch directories. I assume, rcx ThreadX or eCos would be better then Win32 or Posix.
In my "IEc 61499 Real-time Exeuction" book you can find in chapter 6 the description of the exeuction model and structure of FORTE. But I think if you have a first idea on the code structure the fasted would be a video session where I describe and show you the points for starting. Implemetnation and design decisions we can also discuss here in the forum.
I would be more then happy to have your contribution added to FORTE. Please note the Eclipse contribution guidlines [1].
Yes the CPU should have more then enough power to run FORTE. We did experiments with 32MHz arm7 and eCos as operating system and where able to perform real-time closed loop control.
Cheers,
Alois
[1] https://wiki.eclipse.org/Development_Resources/Contributing_via_Git
|
|
|
|
|
|
Re: Does FORTE run on systems without OS [message #1790486 is a reply to message #1790405] |
Mon, 11 June 2018 15:47 |
|
Not really. We currently haven't had any device without operating system. Any specific device you have in mind? But as said above I would nearly always considering an OS noadays. Especially wehn it comes to more advanced networking features (e.g., OPC UA, MQTT).
|
|
|
|
Re: Does FORTE run on systems without OS [message #1790543 is a reply to message #1790538] |
Tue, 12 June 2018 15:19 |
|
We have now a freeRTOS implementation for FORTE as well. We haven't jet had the time on polishing up such it is suitable for open sourcing but we plan to do that. Unfortunately given our current workload I can not tell when we'll achieve that.
CMake is now mandatory. We use CMake to generate some code during the build process. This makes FORTE faster and smaller. But CMake in the end just generates a makefile. Which you then run through make.
For cross compiling with CMake I can recommend the CMake-Gui. There in the very early stages you just select which compiler and where the root directory for you platform specific libs and includes are and thats mostly it. The best for starting I would say is to first compile a FORTE for Windows or Linux just to get you into the process. Then I would say for cross compiling have a look at the raspi docs. FreeRTOS would be pretty similar.
|
|
|
|
Re: Does FORTE run on systems without OS [message #1790622 is a reply to message #1790555] |
Wed, 13 June 2018 16:04 |
|
You are welcome. We made good experiences in either compiling FORTE to a lib and linking it then to the rest of the embedded systems code (e.g., RCX operating system for the Hilscher netX Chips) or the other way rund linking the target code to FORTE for generating the final binary image (e.g., with eCos or freeRTOS).
|
|
|
|
|
|
|
|
Re: Does FORTE run on systems without OS [message #1790819 is a reply to message #1790805] |
Mon, 18 June 2018 14:03 |
|
The IEC 61499 real-time execution book describes in Chapter 6 in detail how the base architecture of FORTE was developed, why? I'm not sure if you need it to port FORTE but it definitely explains the key principles on what we expect from a platform so that we can get certain real-time properties.
|
|
|
|
|
|
|
|
|
|
|
|
Re: Does FORTE run on systems without OS [message #1797172 is a reply to message #1797148] |
Fri, 26 October 2018 16:56 |
|
I must confess I haven't looked into embedOS sofar. I had a quick look on the overview and it looks quite promising. Especially the update features seems to be something one should consider for new products and projects.
But coming back to your question. I think running 4diac FORTE with one of both should work. The advantage of freeRTOS is that there we already provide the basic porting with all architecture specific code you need. So you can focus on just getting it running on your device. For embOS you would need to do this first.
Typically 4diac FORTE should run on such devices. It depends a bit how much memory you have in addition to the internal. Especially when you start exploring the chip and according device I would recommend more. Having from the biging scarce memory resources can greatly slow done your development.
|
|
|
|
|
|
Re: Does FORTE run on systems without OS [message #1797398 is a reply to message #1746839] |
Tue, 30 October 2018 15:26 |
Franz Beckenbauer Messages: 45 Registered: November 2016 |
Member |
|
|
@Frank Radermacher: yes, this was my intention. I wanted to implement Forte on an ESP32 - but only as a proof of concept in our company (for showing that 4Diac/Forte can do useful things with/for our product). The final solution should run on another µC.
@Alois Zoitl: I don't know the Eclipse IoT challenge. I need to read about it. But since I have only very little time to work on this project I have some doubt that I can finish it on-time (whatever the time target is) ...
[Updated on: Tue, 30 October 2018 15:32] Report message to a moderator
|
|
|
|
|
Re: Does FORTE run on systems without OS [message #1797413 is a reply to message #1797410] |
Tue, 30 October 2018 16:19 |
|
@Franz Beckenbauer: the time schedule can definitely be an issue. If we can be of support let us know.
@Frank: Thanks for the background. This is definitely something to keep in mind. freeRTOS recently got quite some support from Amazon. With 4diac FORTE we still try to be as OS agnostic and keep it easily portable to different ones as much as possible. I still don't see a convergence in the devices 4diac FORTE is used in. Although there is a slight tendency that industrial controllers (PLCs and PLC like systems) move more and more to Linux based systems.
@both: your project sound very intersting. we are happy to host a guest blog post in our news section (and according social media channels) if you would like to present some results to our community.
|
|
|
|
|
|
|
|
Re: Does FORTE run on systems without OS [message #1797493 is a reply to message #1797492] |
Wed, 31 October 2018 16:33 |
Franz Beckenbauer Messages: 45 Registered: November 2016 |
Member |
|
|
Then this error message disappears. But there are new error messages:
- xtensa-esp32-elf-g++: error: unrecognized command line option '-mcpu=cortex-m3'
- xtensa-esp32-elf-g++: error: unrecognized command line option '-mthumb'
So, I removed these defines also.
Then the next error is:
- org.eclipse.4diac.forte/src/arch/freeRTOS/forte_sync.h:14:46: fatal error: FreeRTOS_Source/include/FreeRTOS.h: No such file or directory
I think I need to provide the path for the FreeRTOS.h, right?
Here I think I will be running into problems. ESP-IDF (development framework for the ESP32) has its own make system. So, I would like to pull the necesary sources from Forte to the ESP-IDF environment and link this with my other sources. How can I obtain that?
[Updated on: Wed, 31 October 2018 17:16] Report message to a moderator
|
|
|
Re: Does FORTE run on systems without OS [message #1797501 is a reply to message #1797492] |
Wed, 31 October 2018 17:46 |
|
Jose Maria Jesus Cabral Lassalle wrote on Wed, 31 October 2018 16:01
Taking in account that not everyone uses the same as us, the code you mentioned should be removed, and probably add some CMake variables to add your own flags.
I made some first experiments with setting the CMake CFlags, CXXFlags, Linker flags for such setups. And got good results. Therefore I don't think that we need to add additional variables.
|
|
|
|
Re: Does FORTE run on systems without OS [message #1797563 is a reply to message #1797555] |
Thu, 01 November 2018 18:02 |
|
The code is generated when running cmake configure and generate. You'll find then .h and cpp files in your build dir. Furthermore in the src_gen dir and at least in the build_dir/core and build_dir/core/cominfra. Maybe there are more. Every time you add FBs or change the config these files are regenerated. Therefore I can not really recommend this step. Every time when I tried it it was a pain in the ass. We got the best results when we incorporated all build steps into the 4diac FORTE build.
|
|
|
|
|
Re: Does FORTE run on systems without OS [message #1797644 is a reply to message #1797643] |
Sat, 03 November 2018 14:35 |
|
Hi,
regarding your first question. Did you have a look on cross-compiling with CMake. There you can setup toolchain files which could potentially pull in the required include paths. Also I would recommend to not copy you additional code into the FORTE source directory. This makes it very hard to manage changes on both ends. We have since 1.9.0 a flag for external modules directories which can help to add code to 4diac FORTE but keep the code separate.
Also for strategies to not needing to merge both code repos I always found it easier to have one of both sides (i.e., 4diac FORTE or the OS code) as library and link it to the other.
I googled around a bit on lwip and socket interface (we really should finally port forte also to the raw lwip interface) and to my understanding of lwip the select function as well as fd_set should come from a lwip/sockets.h. But I'm not sure how on the ESP-idf newlib and lwip work together.
What also often helps me is to setup a dummy project in the IDE of the target system. And then have a look on all the compiler flags and include paths. This can help to setup a 4diac FORTE build quite a lot. Often I put these options then either in a dedicated CMakeList.txt or in setup shell script for generating the basic environment.
I hope this helps.
Alois
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Does FORTE run on systems without OS [message #1798413 is a reply to message #1798407] |
Sat, 17 November 2018 16:52 |
|
Hi,
that is interesting. I see that in line 42 of arc/arch/freeRTOS/CMakeLists.txt. That exactly this define is added with a comment that this is somehow needed. I think this is coming from Jose. You can give it try by commenting this line.
Alois
|
|
|
Re: Does FORTE run on systems without OS [message #1798415 is a reply to message #1798413] |
Sat, 17 November 2018 18:48 |
Franz Beckenbauer Messages: 45 Registered: November 2016 |
Member |
|
|
When I comment this line, the error disappears. But the comment 'to hide the FD functions' could mean that there is a special reason for this. It would be interesting (maybe important) to know why...
And now there is the next error: In file included from /home/lothar/esp/apps/hello/org.eclipse.4diac.forte/src/arch/fdselecthand.cpp:12:0:
/home/lothar/esp/apps/hello/org.eclipse.4diac.forte/src/arch/freeRTOS/sockhand.h: In function 'int connect(int, const sockaddr*, socklen_t)':
/home/lothar/esp/apps/hello/org.eclipse.4diac.forte/src/arch/freeRTOS/sockhand.h:38:12: error: redefinition of 'int connect(int, const sockaddr*, socklen_t)'
inline int connect(int s, const struct sockaddr *name, socklen_t namelen){
^
In file included from /home/lothar/esp/apps/hello/org.eclipse.4diac.forte/src/arch/freeRTOS/sockhand.h:22:0,
from /home/lothar/esp/apps/hello/org.eclipse.4diac.forte/src/arch/fdselecthand.cpp:12:
/home/lothar/esp/apps/hello/org.eclipse.4diac.forte/src/components/lwip/include/lwip/lwip/sockets.h:576:19: note: 'int connect(int, const sockaddr*, socklen_t)' previously defined here
static inline int connect(int s,const struct sockaddr *name,socklen_t namelen)
The function 'connect' is already defined in sockets.h of lwip as 'lwip_connect_r(s,level,optname,opval,optlen);'. The definition in 'org.eclipse.4diac.forte/src/arch/freeRTOS/sockhand.h' is a function call to 'lwip_connect(s, name, namelen)' which is also defined in lwip. Looking into the sources of the ESP-IDF version of lwip I find that the "xxx_r" - functions are thread safe versions. Which one should I use?
[Updated on: Sat, 17 November 2018 19:50] Report message to a moderator
|
|
|
|
|
Re: Does FORTE run on systems without OS [message #1798421 is a reply to message #1798418] |
Sun, 18 November 2018 09:38 |
|
I think for now using the connect_r function is the better way. On the long run porting forte to the native lwIP interface seems the better option. But this is I guess quite some effort.
The FORTE_TESTS options enables that unit tests are generated for 4diac FORTE. We use BOOST Test as library for writing our unit tests. I don't think it is easily feasible to run these unit tests on the ESP. Therefore it is perfectly fine to disable them.
Currently the main output of your build should be in the 'src' directory which is located directly in you build directory.
|
|
|
|
|
Re: Does FORTE run on systems without OS [message #1798871 is a reply to message #1798802] |
Mon, 26 November 2018 21:04 |
Franz Beckenbauer Messages: 45 Registered: November 2016 |
Member |
|
|
now I put some debug outputs into the code in order to localize where the system crashes. Obviously the code line in question is:Quote:RMT_DEV *poDev = new RMT_DEV; inside the function "void vForteTask( void* pvParameters )". The debug output right before this line is being displayed and the debug output after is not shown and the system crashes.
So, very likely it is related to memory allocation. Do you know how much memory is being allocated by "new RMT_DEV;"?
Additionally I configured the ESP-IDF to give some more debug output when crashing. The debug output now looks like this: Quote:0x40090c60: invoke_abort at E:/msys32/opt/esp/esp-idf/components/esp32/panic.c:680
0x40090e91: abort at E:/msys32/opt/esp/esp-idf/components/esp32/panic.c:680
0x4008fabf: prvInitialiseNewTimer at E:/msys32/opt/esp/esp-idf/components/freertos/timers.c:384 (discriminator 1)
0x4008fb41: xTimerCreate at E:/msys32/opt/esp/esp-idf/components/freertos/timers.c:314
0x400de8a5: CFreeRTOSTimerHandler::CFreeRTOSTimerHandler(CDeviceExecution&) at /home/lothar/esp/apps/hello/org.eclipse.4diac.forte/src/arch/freeRTOS/freertostiha.cpp:20
0x400de8bd: CTimerHandler::createTimerHandler(CDeviceExecution&) at /home/lothar/esp/apps/hello/org.eclipse.4diac.forte/src/arch/freeRTOS/freertostiha.cpp:16
0x400de286: CDeviceExecution::createHandlers(CDeviceExecution&) at /home/lothar/esp/apps/hello/org.eclipse.4diac.forte/out/core/deviceExecutionHandlers.cpp:24
0x400ddec9: CDeviceExecution::CDeviceExecution() at /home/lothar/esp/apps/hello/org.eclipse.4diac.forte/src/core/devexec.cpp:60
0x400de370: CDevice::CDevice(SFBInterfaceSpec const*, unsigned int, unsigned char*, unsigned char*) at /home/lothar/esp/apps/hello/org.eclipse.4diac.forte/src/core/device.h:48
(inlined by) RMT_DEV::RMT_DEV() at /home/lothar/esp/apps/hello/org.eclipse.4diac.forte/src/stdfblib/ita/RMT_DEV.cpp:28
0x400d5132: vForteTask(void*) at E:/msys32/opt/devel/nk_wifi/main/main.cpp:34
0x4008eb11: vPortTaskWrapper at E:/msys32/opt/esp/esp-idf/components/freertos/po
rt.c:403
The final command which makes the system crash is in timers.c in the command:Quote: /* 0 is not a valid value for xTimerPeriodInTicks. */
configASSERT( ( xTimerPeriodInTicks > 0 ) );
So, obvously the timer is being initialized with a period of 0; which is not allowed.
Do you have any hints on this?
[Updated on: Mon, 26 November 2018 21:18] Report message to a moderator
|
|
|
|
|
|
|
Re: Does FORTE run on systems without OS [message #1799219 is a reply to message #1799193] |
Sun, 02 December 2018 17:28 |
Franz Beckenbauer Messages: 45 Registered: November 2016 |
Member |
|
|
Now I changed my build system to completely running under Linux. And I also changed the initialization code as suggested by Jose. But "forteStartInstance(61499, &myForte)" does not return "FORTE_OK". When I try to deploy a test system (e.g. BlinkTest) I get the error message: "Problem: could not connect to device".
I checked the return code of "forteStartInstence": it is "FORTE_DEVICE_ALREADY_STARTED"
When I comment out the check for an already running Forte instance in forte_Init.cpp I get the same error message as a few days before: /home/lothar/esp-idf/components/freertos/timers.c:384 (prvInitialiseNewTimer)- assert failed!
abort() was called at PC 0x40090227 on core 0
0x40090227: prvInitialiseNewTimer at /home/lothar/esp-idf/components/freertos/timers.c:384 (discriminator 1)
I checked if starting a timer via xTimerCreate() and xStartTimer() works in my environment - and this works. So, everything in ESP-IDF is setup correctly. My suspicion is that "getTicksPerSecond()" in Forte does not deliver the right value?
Maybe there is some initialization missing? Do you have any hints what to check next?
[Updated on: Sun, 02 December 2018 19:50] Report message to a moderator
|
|
|
|
Re: Does FORTE run on systems without OS [message #1799274 is a reply to message #1799238] |
Mon, 03 December 2018 19:32 |
Franz Beckenbauer Messages: 45 Registered: November 2016 |
Member |
|
|
Thank you for the hints. The problem was in the definition of configTICK_RATE_HZ in FreeRTOSConfig.h. Here I currently have the additional difficult that I am handling two files of them - one during the creation of the forte library and one during the compilation of the final application under ESP-IDF. The error was that one of them did not have the correct setting for configTICK_RATE_HZ.
After correcting that I now have the next problem:
/home/lothar/esp-idf/components/freertos/queue.c:1442 (xQueueGenericReceive)- assert failed!
abort() was called at PC 0x4008e561 on core 0
Here in freeRTOS source file queue.c the following assertion seems to fail:configASSERT( !( ( pvBuffer == NULL ) && ( pxQueue->uxItemSize != ( UBaseType_t ) 0U ) ) );
I guess this could be related to some memory allocation problem. Could you provide your FreeRTOSConfig.h so that I can compare the configuration options for memory allocation and management of queues?
It would also be interesting to know on which µC you tested your FreeRTOS lwip Forte installation.
[Updated on: Tue, 04 December 2018 19:46] Report message to a moderator
|
|
|
|
|
Re: Does FORTE run on systems without OS [message #1799412 is a reply to message #1799346] |
Thu, 06 December 2018 10:54 |
Franz Beckenbauer Messages: 45 Registered: November 2016 |
Member |
|
|
Now I compared the two FreeRTOS.h files. But I could not find any relevant differences concerning memory allocation or queues. Unfortunately I do not have a debugging tool available; and when I put printf into the code in order to see whats going on I do not see any output - printf seems to be not working.
My next steps will be:
- using latest Forte 1.10.0 (which was recently released); I see that there are several changes in the file fortenew.h
- trying to integrate ESP-IDF debugging macros (ESP_LOGx() macros) into Forte
Do you have any other hint where to look for the root cause of the problem?
[Updated on: Thu, 06 December 2018 17:51] Report message to a moderator
|
|
|
|
Re: Does FORTE run on systems without OS [message #1799478 is a reply to message #1799446] |
Fri, 07 December 2018 13:30 |
|
I'll try to add my points to this issue. Normally we are rather sensitive to memory consuption and working hard to reduce it. In 1.10.0 we achieved here again a few bytes per FB. Reducing the number of enabled modules could definitly be a starting point to track down where the problem is.
However I fear it is something more fundamental. I remember when we started our work with freeRTOS that we still had issues that not on all places forte_alloc and forte_free was used. I thought we have this under control now. But you could check in your map file if there are references to other allocation schemes. In your previous messages i noticed that you ESP32 is somehow using newlib together with freeRTOS. I know that newlib has an own heap managment. Maybe you can check in the docs how to correctly use this and who is reponsible for heap newlib or freeRTOS. You may have to then adjust fortealloc.h accordingly. You could also add here the ESP_LOG macros to check if allocation is always working.
Another problem could be if you have logging enabled that the default forte loging goes to printf. This can lead to problems. For a quick test you could disable the FORTE logging in cmake.
Another good starting point is looking in the map file generated by the linker. There you could see if strange stuff has been added.
I hope this helps so that we can tracke this down.
|
|
|
|
Re: Does FORTE run on systems without OS [message #1799598 is a reply to message #1799542] |
Mon, 10 December 2018 20:35 |
|
Thanks for the investigation. If lwIP is using the default malloc functions i would assume these are the ones provide from newlib. Currently FORTE for freeRTOS is configured to use the pvPortMalloc function. I don't know if both are targeting the same memory manager. But for a quick test you could replace the freeRTOS specific mallacs with the default implemetnation. That means uncommenting the #include "../genfortealloc.h" line and commenting the rest.
|
|
|
Re: Does FORTE run on systems without OS [message #1799646 is a reply to message #1799598] |
Tue, 11 December 2018 20:25 |
Franz Beckenbauer Messages: 45 Registered: November 2016 |
Member |
|
|
Now I modified fortealloc.h as you suggested: including gentfortealloc.h and commenting out forte_free() and forte_malloc(). Unfortunately the error remains the same. Here is a backtrace from the crash report:assertion "res == coreID || res == portMUX_FREE_VAL" failed: file "/home/lothar/esp-idf/components/freertos/portmux_impl.inc.h", line 105, function: vPortCPUAcquireMutexIntsDisabledInternal
abort() was called at PC 0x400e963b on core 0
0x400e963b: __assert_func at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:63 (discriminator 8)
Backtrace: 0x4008ed3c:0x3ffbd750 0x4008ef65:0x3ffbd770 0x400e963b:0x3ffbd790 0x4009266d:0x3ffbd7c0 0x400916b4:0x3ffbd7f0 0x400e64e4:0x3ffbd830 0x400e6095:0x3ffbd850 0x40093b16:0x3ffbd870 0x40093b49:0x3ffbd890 0x40093c68:0x3ffbd8c0 0x40091949:0x3ffbd8f0
0x4008ed3c: invoke_abort at /home/lothar/esp-idf/components/esp32/panic.c:680
0x4008ef65: abort at /home/lothar/esp-idf/components/esp32/panic.c:680
0x400e963b: __assert_func at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:63 (discriminator 8)
0x4009266d: vPortCPUAcquireMutexIntsDisabledInternal at /home/lothar/esp-idf/components/freertos/tasks.c:3537
(inlined by) vPortCPUAcquireMutexIntsDisabled at /home/lothar/esp-idf/components/freertos/portmux_impl.h:98
(inlined by) vTaskEnterCritical at /home/lothar/esp-idf/components/freertos/tasks.c:4231
0x400916b4: xQueueGenericReceive at /home/lothar/esp-idf/components/freertos/queue.c:2037
0x400e64e4: CFreeRTOSSyncObject::lock() at /home/lothar/esp/apps/forte/src/arch/freeRTOS/../genfortealloc.h:20
(inlined by) CCriticalRegion::CCriticalRegion(CFreeRTOSSyncObject&) at /home/lothar/esp/apps/forte/src/arch/../core/utils/criticalregion.h:20
(inlined by) CTimerHandler::nextTick() at /home/lothar/esp/apps/forte/src/arch/timerha.cpp:97
0x400e6095: CFreeRTOSTimerHandler::vCallbackFunction(void*) at /home/lothar/esp/apps/forte/src/arch/freeRTOS/freertostiha.cpp:47
0x40093b16: prvProcessExpiredTimer at /home/lothar/esp-idf/components/freertos/timers.c:523
0x40093b49: prvProcessTimerOrBlockTask at /home/lothar/esp-idf/components/freertos/timers.c:570
0x40093c68: prvTimerTask at /home/lothar/esp-idf/components/freertos/timers.c:543 (discriminator 1)
0x40091949: vPortTaskWrapper at /home/lothar/esp-idf/components/freertos/port.c:355 (discriminator 1)
From this we can see that the last line of code executed from Forte is: "genfortealloc.h:20" which is: "free(pa_pvData);". Then the next function call shall be in "xQueueGenericReceive at /home/lothar/esp-idf/components/freertos/queue.c:2037". This looks very weird to me - in free() there is very likely no call to any function in queue.c. I would expect that this is the place where the system actually crashes. So, I guess that the problem still is somewhere in the memory allocation functions.
I also tested again with and without the use of external SPI-RAM als heap memory. The error message is exactly the same in both cases.
When I compare this map file to a map file of another (working) application on the ESP32 I see no significant differences concerning the use of malloc and free: in both cases the _malloc_r and _free_r functions seem to be used. This could indicate that the problem is in a totally different location? I am lost...
[Updated on: Tue, 11 December 2018 21:01] Report message to a moderator
|
|
|
Re: Does FORTE run on systems without OS [message #1799647 is a reply to message #1799646] |
Tue, 11 December 2018 22:40 |
|
Thanks for the stack trace. This really shades some more light on the issue. I don't think it has anything to do with memory allocation. However I must say that the stack trace is a bit confusing. Which optimization level are you currently compiling with? Could you give -O0 a try to see if the stack trace is clearer.
The reason I'm asking is that the problem seems to be that an uninitialized mutex should get locked. Hover in the method which is acquiring the mutex this would only happen if a timed FB (i.e., E_CYCLE or E_DELAY has been started. Are you already at an stage where FBs are running?
|
|
|
Re: Does FORTE run on systems without OS [message #1799669 is a reply to message #1799647] |
Wed, 12 December 2018 07:22 |
Franz Beckenbauer Messages: 45 Registered: November 2016 |
Member |
|
|
Now I set in Forte CMake -O0 and in ESP-IDF for debug mode optimization is set to -Og. Now the backtrace looks slightly different but with the same final crash: assertion "res == coreID || res == portMUX_FREE_VAL" failed: file "/home/lothar/esp-idf/components/freertos/portmux_impl.inc.h", line 105, function: vPortCPUAcquireMutexIntsDisabledInternal
abort() was called at PC 0x400f6acb on core 0
0x400f6acb: __assert_func at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:63 (discriminator 8)
Backtrace: 0x4008ed54:0x3ffbd850 0x4008ef7d:0x3ffbd870 0x400f6acb:0x3ffbd890 0x40092685:0x3ffbd8c0 0x400916cc:0x3ffbd8f0 0x400d7296:0x3ffbd930 0x400d72d5:0x3ffbd960 0x400d8363:0x3ffbd990 0x400f08de:0x3ffbd9d0 0x40093b2e:0x3ffbda00 0x40093b61:0x3ffbda20 0x40093c80:0x3ffbda50 0x40091961:0x3ffbda80
0x4008ed54: invoke_abort at /home/lothar/esp-idf/components/esp32/panic.c:680
0x4008ef7d: abort at /home/lothar/esp-idf/components/esp32/panic.c:680
0x400f6acb: __assert_func at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:63 (discriminator 8)
0x40092685: vPortCPUAcquireMutexIntsDisabledInternal at /home/lothar/esp-idf/components/freertos/tasks.c:3537
(inlined by) vPortCPUAcquireMutexIntsDisabled at /home/lothar/esp-idf/components/freertos/portmux_impl.h:98
(inlined by) vTaskEnterCritical at /home/lothar/esp-idf/components/freertos/tasks.c:4231
0x400916cc: xQueueGenericReceive at /home/lothar/esp-idf/components/freertos/queue.c:2037
0x400d7296: CFreeRTOSSyncObject::lock() at /home/lothar/esp/apps/forte/src/arch/freeRTOS/forte_sync.h:40
0x400d72d5: CCriticalRegion::CCriticalRegion(CFreeRTOSSyncObject&) at /home/lothar/esp/apps/forte/src/arch/../core/utils/criticalregion.h:20
0x400d8363: CTimerHandler::nextTick() at /home/lothar/esp/apps/forte/src/arch/timerha.cpp:97
0x400f08de: CFreeRTOSTimerHandler::vCallbackFunction(void*) at /home/lothar/esp/apps/forte/src/arch/freeRTOS/freertostiha.cpp:47
0x40093b2e: prvProcessExpiredTimer at /home/lothar/esp-idf/components/freertos/timers.c:523
0x40093b61: prvProcessTimerOrBlockTask at /home/lothar/esp-idf/components/freertos/timers.c:570
0x40093c80: prvTimerTask at /home/lothar/esp-idf/components/freertos/timers.c:543 (discriminator 1)
0x40091961: vPortTaskWrapper at /home/lothar/esp-idf/components/freertos/port.c:355 (discriminator 1)
Now the first function calls are the same. The difference comes after the call in "criticalregion.h:20" where now there is a call to "forte_sync.h:40". The rest again is the same.
To your question: no, I am not running any tasks. I am just trying to initialize the Forte system using: forteGlobalInitialize();
ESP_LOGI(TAG, "2. free heap: %d", heap_caps_get_free_size(MALLOC_CAP_8BIT));
TForteInstance myForte;
ESP_LOGI(TAG, "3. free heap: %d", heap_caps_get_free_size(MALLOC_CAP_8BIT));
int forteStartStatus;
if(FORTE_OK != (forteStartStatus = forteStartInstance(61499, &myForte))){
//something went wrong, handle it
ESP_LOGI(TAG, "Forte init failed");
if(forteStartStatus == FORTE_DEVICE_ALREADY_STARTED)
ESP_LOGI(TAG, "Device already started");
else if (forteStartStatus == FORTE_WRONG_ENDIANESS)
ESP_LOGI(TAG, "wrong endianess");
else if (forteStartStatus == FORTE_WRONG_PARAMETERS)
ESP_LOGI(TAG, "wrong parameters");
else if (forteStartStatus == FORTE_ARCHITECTURE_NOT_READY)
ESP_LOGI(TAG, "architecture not ready");
} else {
//forte started
ESP_LOGI(TAG, "Forte started");
forteJoinInstance(myForte); //wait your forte to end
}
In my log I see the last logging message: "ESP_LOGI(TAG, "3. free heap: %d", heap_caps_get_free_size(MALLOC_CAP_8BIT));"; after this the system crashes - obviously in forteStartInstance(). I am still not able to connect to Forte using 4diac and so I am not able to download or start any program.
|
|
|
Re: Does FORTE run on systems without OS [message #1799676 is a reply to message #1799669] |
Wed, 12 December 2018 09:05 |
|
Thanks for the update. Ok this is what I've expected to see after you showed the last stack trace. My assumption is that somewhere after creating the FORTE timer during the device setup we have a segfault leading the timer callback into corrupted memory.
Now we need to find out where FORTE dies. I have an idea for that, which caused us grieve on several platforms. For that it would be great if I could see your map file ( you can also mail it privately to me alois.zoitl (at) gmx.at) and also your linker file (ending with .ld). In order that FORTE is working correctly we need a CTOR section in the linker file and that the CTOR sections is invoked during startup. The CTOR section is the section where all static classes and class members get there constructor invoked. We use this to automatically build up FORTE's typelibrary.
|
|
|
Re: Does FORTE run on systems without OS [message #1799689 is a reply to message #1799676] |
Wed, 12 December 2018 12:19 |
|
I looked through the map file, as well as in the docs of esp-idf. I think the c++ startup calling the global construtors should be in the espif. At least this is what I found in components/esp32/cpu_start.c which should handle the startup process.
I think a potential next step could be to add more ESP_LOGIs also to forte code. Or what would even be better to do remote debugging and stepping through the code to see what really happens.
|
|
|
|
|
|
|
|
|
|
Re: Does FORTE run on systems without OS [message #1821916 is a reply to message #1821904] |
Sat, 22 February 2020 21:51 |
|
Oh I think I have mixed up the ESP numbers then.
Jose did a great job in improving freeRTOS support and documentation. I have two boards on my desk where I need to test 4diac FORTE with freeRTOS on. I hope I find time soon and update the documentation if needed.
|
|
|