The initial analysis is provided in the document MCU (DashCam) versions and functionality.pdf. The final conclusion is:
The file mtk_2.0_dashcam_1.2.zip does not match the binary provided by Amantya such as CameraManager_v1.3.1
MCU_DashCam_MCU_Code_V1.1.zip does not math MCU application running on dash camera provided. The log generated by MCU application could not be found in the source code provided. For example we could not find the following messages:
The source code mtk_2.0_dashcam_1.2.zip could not be built. It contains the code errors which does not allow to build the source code. We have to correct them before.
The application we built after the fix doesn't interact with the MCU. It successfully sends requests, but doesn't receive any response from the MCU. The log shows that the application freezes when reading through the serial port.
It is assumed that the reason why the application cannot receive a response from the MCU is that the format of the request sent by the application to the MCU does not match what the MCU expects. We send the request of size 59, but at the same time, the microcontroller source code expects a request of size 56.
The format description we can get from DashCamSoftwareArchitecture_v1.1.pdf does not contain an exact description of the request format expected by MCU. Just a description of the request fields, no indication of what the message length should be.
More detailed conclusion (with images) could be found in MCU (DashCam) versions and functionality.pdf at:
Verizon Dashcam Controller Software Architecture: https://rucola-nn.quickconnect.to/d/f/15QIInR4FT8CYBdFvs8IleTbBkL4fLlX
The initial analysis is provided in the document MCU (DashCam) versions and functionality.pdf. The final conclusion is:
The file mtk_2.0_dashcam_1.2.zip does not match the binary provided by Amantya such as CameraManager_v1.3.1
MCU_DashCam_MCU_Code_V1.1.zip does not math MCU application running on dash camera provided. The log generated by MCU application could not be found in the source code provided. For example we could not find the following messages:
“MCU App Version”, “RTC Date”, “USB Detected Type”, “RGB Status”
The only log we can see in the source code:
LOG(LOG_INFO,"Voltage: %u mV\r\n SOC : %u%% \r\n Current : %d mA\r\n Design Capacity : %u mAh\r\n", ...
The source code mtk_2.0_dashcam_1.2.zip could not be built. It contains the code errors which does not allow to build the source code. We have to correct them before.
The application we built after the fix doesn't interact with the MCU. It successfully sends requests, but doesn't receive any response from the MCU. The log shows that the application freezes when reading through the serial port.
It is assumed that the reason why the application cannot receive a response from the MCU is that the format of the request sent by the application to the MCU does not match what the MCU expects. We send the request of size 59, but at the same time, the microcontroller source code expects a request of size 56.
The format description we can get from DashCamSoftwareArchitecture_v1.1.pdf does not contain an exact description of the request format expected by MCU. Just a description of the request fields, no indication of what the message length should be.
More detailed conclusion (with images) could be found in MCU (DashCam) versions and functionality.pdf at:
https://rucola-nn.quickconnect.to/d/f/16baPa0EN78EAZgcLDOXVFBsApYNLFAg
#44 MCU (DashCam) versions and functionality research
Description of the issue
The mvcamera application running on the MPU cannot interact with MCU services that handle camera peripherals.
For this reason, the application cannot collect all the required KPIs.
It also cannot interact with the user because it cannot obtain the state of buttons or report the app's state via LEDs.
What was done to solve the problem
An Amantya camera app was built from the mtk_2.0_dashcam_1.2.zip source code and tested on two dashcams.
The source code, executable file, and log can be found here:
DashCam-src-v1.2-corrected-by-mview-team.zip
The mcutest application was developed for testing various interactions with the microcontroller.
The application includes two main versions, codenamed 1.1.0 and 1.2.0.
Version 1.1.0 is a non-blocking version of the MCU read and uses the select() function to check for data in the UART.
Version 1.2.0 is a blocking version of the MCU read and is almost identical to the code in Amntya mtk_2.0_dashcam_1.2.zip.
These versions can be called as follows:
$ ./mcutest -v 1.1.0 -c 3 -p /dev/ttyS1 -b 9600
$ ./mcutest -v 1.2.0 -c 2 -p /dev/ttyS1
Research results
Unfortunately, it was not possible to read the data from the MCU.
Logs were received when running the test application provided:
mcutest-1.1.0.log
mcutest-1.2.0.log
Assumption about the causes of the issue
The MCU accepts the request from the MPU but interprets it as invalid.
Unfortunately, we don't have the latest source code from Amantya, specifically 1.3.1 for the mtk_2.0 dashcam application
and 1.1.3 for the MCU services. From the documentation, we know that the latest version for the MCU is 1.1.4.
#44 MCU (DashCam) versions and functionality research
### Description of the issue ###
* The mvcamera application running on the MPU cannot interact with MCU services that handle camera peripherals.
* For this reason, the application cannot collect all the required KPIs.
* It also cannot interact with the user because it cannot obtain the state of buttons or report the app's state via LEDs.
### What was done to solve the problem ###
* An Amantya camera app was built from the mtk_2.0_dashcam_1.2.zip source code and tested on two dashcams.
The source code, executable file, and log can be found here:
- DashCam-src-v1.2-corrected-by-mview-team.zip
* The mcutest application was developed for testing various interactions with the microcontroller.
The application includes two main versions, codenamed 1.1.0 and 1.2.0.
- Version 1.1.0 is a non-blocking version of the MCU read and uses the select() function to check for data in the UART.
- Version 1.2.0 is a blocking version of the MCU read and is almost identical to the code in Amntya mtk_2.0_dashcam_1.2.zip.
These versions can be called as follows:
$ ./mcutest -v 1.1.0 -c 3 -p /dev/ttyS1 -b 9600
$ ./mcutest -v 1.2.0 -c 2 -p /dev/ttyS1
### Research results ###
* Unfortunately, it was not possible to read the data from the MCU.
* Logs were received when running the test application provided:
- mcutest-1.1.0.log
- mcutest-1.2.0.log
### Assumption about the causes of the issue ###
* The MCU accepts the request from the MPU but interprets it as invalid.
* Unfortunately, we don't have the latest source code from Amantya, specifically 1.3.1 for the mtk_2.0 dashcam application
and 1.1.3 for the MCU services. From the documentation, we know that the latest version for the MCU is 1.1.4.
### Folder with files ###
https://rucola-nn.direct.quickconnect.to:5001/?launchApp=SYNO.SDS.Drive.Application&sharing=true#file_id=929966004212118775
sgolubev
Verizon Dashcam Controller Software Architecture: https://rucola-nn.quickconnect.to/d/f/15QIInR4FT8CYBdFvs8IleTbBkL4fLlX
The initial analysis is provided in the document MCU (DashCam) versions and functionality.pdf. The final conclusion is:
The file mtk_2.0_dashcam_1.2.zip does not match the binary provided by Amantya such as CameraManager_v1.3.1
MCU_DashCam_MCU_Code_V1.1.zip does not math MCU application running on dash camera provided. The log generated by MCU application could not be found in the source code provided. For example we could not find the following messages:
“MCU App Version”, “RTC Date”, “USB Detected Type”, “RGB Status”
The only log we can see in the source code:
LOG(LOG_INFO,"Voltage: %u mV\r\n SOC : %u%% \r\n Current : %d mA\r\n Design Capacity : %u mAh\r\n", ...
The source code mtk_2.0_dashcam_1.2.zip could not be built. It contains the code errors which does not allow to build the source code. We have to correct them before.
The application we built after the fix doesn't interact with the MCU. It successfully sends requests, but doesn't receive any response from the MCU. The log shows that the application freezes when reading through the serial port.
It is assumed that the reason why the application cannot receive a response from the MCU is that the format of the request sent by the application to the MCU does not match what the MCU expects. We send the request of size 59, but at the same time, the microcontroller source code expects a request of size 56.
The format description we can get from DashCamSoftwareArchitecture_v1.1.pdf does not contain an exact description of the request format expected by MCU. Just a description of the request fields, no indication of what the message length should be.
More detailed conclusion (with images) could be found in MCU (DashCam) versions and functionality.pdf at:
https://rucola-nn.quickconnect.to/d/f/16baPa0EN78EAZgcLDOXVFBsApYNLFAg
Develop test app based on Amantia source code.
Branch: https://lab.rclmx.ru/gogs/MView/5gcamera/src/test-mcu
#44 MCU (DashCam) versions and functionality research
Description of the issue
What was done to solve the problem
The source code, executable file, and log can be found here:
DashCam-src-v1.2-corrected-by-mview-team.zip
The mcutest application was developed for testing various interactions with the microcontroller.
The application includes two main versions, codenamed 1.1.0 and 1.2.0.
These versions can be called as follows:
$ ./mcutest -v 1.1.0 -c 3 -p /dev/ttyS1 -b 9600
$ ./mcutest -v 1.2.0 -c 2 -p /dev/ttyS1
Research results
Logs were received when running the test application provided:
Assumption about the causes of the issue
Folder with files
https://rucola-nn.direct.quickconnect.to:5001/?launchApp=SYNO.SDS.Drive.Application&sharing=true#file_id=929966004212118775