EPOS issueshttps://gitlab.lisha.ufsc.br/epos/epos/-/issues2023-11-18T17:07:40Zhttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/20RISCV sp and epc corruption2023-11-18T17:07:40ZThiago Augusto BewiahnRISCV sp and epc corruptionSporadic exceptions appear in most applications, but at an increased rate when running multicore with kernel (i.e. philosophers_dinner). Kernel and user stack pointers get swapped and corrupted, or epc is zeroed.
Timer interrupt influen...Sporadic exceptions appear in most applications, but at an increased rate when running multicore with kernel (i.e. philosophers_dinner). Kernel and user stack pointers get swapped and corrupted, or epc is zeroed.
Timer interrupt influence was already discarded. The main hypotheses are in Context's push/pop or interrupt handling, with a possibility of not dealing with privilege chances correctly.
Initial debug code was committed to the branch 'bewiahn'.EPOS 2.3Thiago Augusto BewiahnThiago Augusto Bewiahnhttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/19Follow-up from "FZ3"2023-10-26T17:01:13ZAntônio Augusto Fröhlichguto@lisha.ufsc.brFollow-up from "FZ3"The following discussions from !44 should be addressed:
- [ ] @guto started a [discussion](https://gitlab.lisha.ufsc.br/epos/epos/-/merge_requests/44#note_1032):
> Doesn't make sense: there are two shorts in sequence!
- [ ] @guto...The following discussions from !44 should be addressed:
- [ ] @guto started a [discussion](https://gitlab.lisha.ufsc.br/epos/epos/-/merge_requests/44#note_1032):
> Doesn't make sense: there are two shorts in sequence!
- [ ] @guto started a [discussion](https://gitlab.lisha.ufsc.br/epos/epos/-/merge_requests/44#note_1036): (+1 comment)
> ???
- [ ] @guto started a [discussion](https://gitlab.lisha.ufsc.br/epos/epos/-/merge_requests/44#note_1037):
> This is done by the ERR handling if sterically_debugged is set!EPOS 2.3Leonardo Passig HorstmannLeonardo Passig Horstmannhttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/17Bug Report: Philosophers Dinner @ VisionFive22023-09-26T22:44:49ZJoão Paulo BonomoBug Report: Philosophers Dinner @ VisionFive2The philosophers dinner isn't working in **EPOS for INE5424** @ VisionFive 2.
The code generates an exception (id=5) that **means data protection violation (read)**.
With debugs, we can see that the exception is in **epc=0x00000000400012...The philosophers dinner isn't working in **EPOS for INE5424** @ VisionFive 2.
The code generates an exception (id=5) that **means data protection violation (read)**.
With debugs, we can see that the exception is in **epc=0x000000004000129a**, following the objdump, we see that this address contains the instruction {_ld a0,0(s1)_}. The protection violation occurs in register _a0_. This is inside the philosopher function, and the exception occurs before the chopstick Semaphore call _p()_ (line 93). I commented the _Delay thinking(1000000);_ (line 86), but the exception still occurs. In log file, we see that _wakeup_all()_ is the last function called before the exception occurs. This function is called 11 times in philosophers dinner, but the exception occursrs just in the 5 first (1 time for each philosopher thread before _Thread exit()_) and the debug added (line 292 in thread.cc) inside the _if(!q->empty())_ conditional wasn't printed.
To see the code, follow to
[https://gitlab.lisha.ufsc.br/epos/ine5424/-/tree/nic-plic-integration](epos/ine5424 nic-plic-integration).
OBS: The philosophers dinner execution log at VisionFive 2 and objdump are attached at this post.
[log_philosophers_dinner.txt](/uploads/fd7398fa7aaaad77acb109ca4b4ff848/log_philosophers_dinner.txt)
[objdump_symbols.txt](/uploads/f7f0fc72ebc45847b75fdb172f717919/objdump_symbols.txt)João Paulo BonomoJoão Paulo Bonomohttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/16NIC is defined for eMoteIII, which makes no sense2023-08-18T18:58:34ZLucas YotsuiNIC is defined for eMoteIII, which makes no senseI've been having some trouble when trying to compile the test program for the EposMoteIII. After talking to professor Antônio Augusto Fröhlich we were able to track it down to a couple macros on the _include/system/config.h_ file.
I cou...I've been having some trouble when trying to compile the test program for the EposMoteIII. After talking to professor Antônio Augusto Fröhlich we were able to track it down to a couple macros on the _include/system/config.h_ file.
I couldn't figure out a way to make a pull request so I'll post the fix here: All it takes is to remove lines 132-135 from the config.h files and it just works.
Before changes:
```cpp
#ifdef __mmod_emote3__
#define __cortex_m__
#define __cortex_m3__
#define __TSC_H __HEADER_ARCH(tsc)
#define __EEPROM_H __HEADER_MACH(eeprom)
#define __UART_H __HEADER_MACH(uart)
#define __SPI_H __HEADER_MACH(spi)
#define __RS485_H __HEADER_MACH(rs485)
#define __USB_H __HEADER_MACH(usb)
#define __I2C_H __HEADER_MACH(i2c)
#define __GPIO_H __HEADER_MACH(gpio)
#define __ADC_H __HEADER_MACH(adc)
#define __PWM_H __HEADER_MACH(pwm)
#define __WATCHDOG_H __HEADER_MACH(watchdog)
#define __NIC_H __HEADER_MACH(nic)
#define __modem__
#define __ieee802_15_4__
#define __tstp__
#define __ACCELEROMETER_H __HEADER_TRAN(accelerometer)
#define __GYROSCOPE_H __HEADER_TRAN(gyroscope)
#define __CO2_SENSOR_H __HEADER_TRAN(co2_sensor)
#define __PLUVIOMETER_H __HEADER_TRAN(pluviometer)
#define __PRESSURE_SENSOR_H __HEADER_TRAN(pressure_sensor)
#define __THERMOMETER_H __HEADER_TRAN(thermometer)
#define __HYGROMETER_H __HEADER_TRAN(hygrometer)
#endif
```
After changes:
```cpp
#ifdef __mmod_emote3__
#define __cortex_m__
#define __cortex_m3__
#define __TSC_H __HEADER_ARCH(tsc)
#define __EEPROM_H __HEADER_MACH(eeprom)
#define __UART_H __HEADER_MACH(uart)
#define __SPI_H __HEADER_MACH(spi)
#define __RS485_H __HEADER_MACH(rs485)
#define __USB_H __HEADER_MACH(usb)
#define __I2C_H __HEADER_MACH(i2c)
#define __GPIO_H __HEADER_MACH(gpio)
#define __ADC_H __HEADER_MACH(adc)
#define __PWM_H __HEADER_MACH(pwm)
#define __WATCHDOG_H __HEADER_MACH(watchdog)
#define __ACCELEROMETER_H __HEADER_TRAN(accelerometer)
#define __GYROSCOPE_H __HEADER_TRAN(gyroscope)
#define __CO2_SENSOR_H __HEADER_TRAN(co2_sensor)
#define __PLUVIOMETER_H __HEADER_TRAN(pluviometer)
#define __PRESSURE_SENSOR_H __HEADER_TRAN(pressure_sensor)
#define __THERMOMETER_H __HEADER_TRAN(thermometer)
#define __HYGROMETER_H __HEADER_TRAN(hygrometer)
#endif
```
OBS: Btw, this fix was tested for both the develop and master branch and it worked for bothhttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/10Constexpr arrays in pmu_test2021-01-27T02:58:33ZJosé Luis Conradi HoffmannConstexpr arrays in pmu_testThe new PMU constexpr *_events* array is working fine in the Clerk. However, its usage in pmu_test generates a compile-time error indicating an undefined reference to the *_events* array, even though the process is very similar (PMU::con...The new PMU constexpr *_events* array is working fine in the Clerk. However, its usage in pmu_test generates a compile-time error indicating an undefined reference to the *_events* array, even though the process is very similar (PMU::config in a new inside the inline function vs. config as an explicit call inside main). All the necessary information seems to be available at compile-time, and the constexpr vector should not be necessary during the linkage process. We still need to investigate this problem.https://gitlab.lisha.ufsc.br/epos/epos/-/issues/14NIC test2020-05-03T23:20:36ZAntônio Augusto Fröhlichguto@lisha.ufsc.brNIC testNIC test is tesing only one NIC at a time and only for PC. We should have tests for all NICs just by changing the traits. It is also not testing some specificities of each NIC, like the new Configuration interface.NIC test is tesing only one NIC at a time and only for PC. We should have tests for all NICs just by changing the traits. It is also not testing some specificities of each NIC, like the new Configuration interface.EPOS 2.2.2José Luis Conradi HoffmannJosé Luis Conradi Hoffmannhttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/13Raspberry Pi32020-03-10T22:43:52ZJosé Luis Conradi HoffmannRaspberry Pi3Tests needed:
1) RT_Thread; (DONE)
2) Monitor; (DONE)
3) Thread Statistics Accounting; (DONE)
4) Add FANN;
5) Reconfigure Stress Test;
General Changes needed:
1) Add a watchdog for the reboot.
2) Rework UART Base address;
3) Add SPI imp...Tests needed:
1) RT_Thread; (DONE)
2) Monitor; (DONE)
3) Thread Statistics Accounting; (DONE)
4) Add FANN;
5) Reconfigure Stress Test;
General Changes needed:
1) Add a watchdog for the reboot.
2) Rework UART Base address;
3) Add SPI implementation;José Luis Conradi HoffmannJosé Luis Conradi Hoffmannhttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/5Math test2020-03-09T11:40:42ZAntônio Augusto Fröhlichguto@lisha.ufsc.brMath testUtility math.h is not being tested. Simple tests should be added (e.g. pow(sin(x), 2) + pow(cos(x), 2) = 1).Utility math.h is not being tested. Simple tests should be added (e.g. pow(sin(x), 2) + pow(cos(x), 2) = 1).EPOS 2.2José Luis Conradi HoffmannJosé Luis Conradi Hoffmannhttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/9EDF Priority update2020-01-30T15:07:48ZJosé Luis Conradi HoffmannEDF Priority updateThe current implementation of priority as an int incur that long runs using EDF scheduling will generate priority inversion, thus a thread that reaches a negative priority will be the highest priority of the system, generating a run-time...The current implementation of priority as an int incur that long runs using EDF scheduling will generate priority inversion, thus a thread that reaches a negative priority will be the highest priority of the system, generating a run-time bug. However, modifying the type of priority to be related to the Life_Span Traits when using EDF (and its derivatives) will generate a lot of overhead when using a 64bits attribute in a 32bits architecture, due to the high frequency of scheduling operations. A new way to reset the priority count should be provided.https://gitlab.lisha.ufsc.br/epos/epos/-/issues/8std:tuple2020-01-14T12:51:21ZAntônio Augusto Fröhlichguto@lisha.ufsc.brstd:tupleWe definitely need something like std:tuple for EPOS. However, as always, the STL implementation (https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/tuple) is too heavy and too zealous for things that never happen...We definitely need something like std:tuple for EPOS. However, as always, the STL implementation (https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/tuple) is too heavy and too zealous for things that never happen in system-land. Would someone date to produce a light version of it (similar to what I did for OStream and meta.h)?EPOS 2.3https://gitlab.lisha.ufsc.br/epos/epos/-/issues/6Makefiles dependencies2020-01-07T00:24:50ZAntônio Augusto Fröhlichguto@lisha.ufsc.brMakefiles dependenciesOur makefiles include makedefs, which parses traits again for each include. Exporting the variables from the main makefile, so descendant makefiles would not need to (re)-include makedefs seems an easy solution, but it didn't work as exp...Our makefiles include makedefs, which parses traits again for each include. Exporting the variables from the main makefile, so descendant makefiles would not need to (re)-include makedefs seems an easy solution, but it didn't work as expected.EPOS 2.2https://gitlab.lisha.ufsc.br/epos/epos/-/issues/4SPI Slave2020-01-02T22:33:06ZAntônio Augusto Fröhlichguto@lisha.ufsc.brSPI SlaveImplement the slave mode for EPOS' SPI @ EPOSMote IIIImplement the slave mode for EPOS' SPI @ EPOSMote IIIEPOS 2.2Alek FröhlichAlek Fröhlich2020-01-10