Today, I found my ad lying flat on the drawing board. No matter how inhumane I operate, I won’t display a green fork to report an error.
Reason 1: press the shortcut key D + R to check whether enable in rules and constraints is checked
Reason 2: the shortcut key t + D determines whether all rules in the rules to check of the rule checker are online. My ad doesn’t know when the online tick is gone, so the rule checker directly fishes, resulting in no error reporting.
There are a lot of mce log we can check from the mcelog file. Indeed, this is a HW issue and some part is defective one, almost is memory. But a lot of vender don’t want to replace it for this is a correctable error. And we can also check this error at ilom (different vendor have different name but almost of them is built by polit 3,4 arch) as bellow.
2021-11-14/20:09:00 ereport.cpu.intel.quickpath.mem_ce@/SYS/MB/P1/D3
count = 0x1
system_component_firmware_versions = (ILOM)5.0.1.28 r140973,(BIOS)38340900
2021-11-14/20:17:57 ereport.cpu.intel.quickpath.mem_ce@/SYS/MB/P1/D3
count = 0x1
system_component_firmware_versions = (ILOM)5.0.1.28 r140973,(BIOS)38340900
—
If you want to disable them for some monitor policy pls check as bellow
Solution:
Machine Check Exception
mce=off
Disable machine check
mce=no_cmci
Disable CMCI(Corrected Machine Check Interrupt) that
Intel processor supports. Usually this disablement is
not recommended, but it might be handy if your hardware
is misbehaving.
Note that you’ll get more problems without CMCI than with
due to the shared banks, i.e. you might get duplicated
error logs.
mce=dont_log_ce
Don’t make logs for corrected errors. All events reported
as corrected are silently cleared by OS.
This option will be useful if you have no interest in any
of corrected errors.
mce=ignore_ce
Disable features for corrected errors, e.g. polling timer
and CMCI. All events reported as corrected are not cleared
by OS and remained in its error banks.
Usually this disablement is not recommended, however if
there is an agent checking/clearing corrected errors
(e.g. BIOS or hardware monitoring applications), conflicting
with OS’s error handling, and you cannot deactivate the agent,
then this option will be a help.
mce=bootlog
Enable logging of machine checks left over from booting.
Disabled by default on AMD because some BIOS leave bogus ones.
If your BIOS doesn’t do that it’s a good idea to enable though
to make sure you log even machine check events that result
in a reboot. On Intel systems it is enabled by default.
mce=nobootlog
Disable boot machine check logging.
mce=tolerancelevel[,monarchtimeout] (number,number)
tolerance levels:
0: always panic on uncorrected errors, log corrected errors
1: panic or SIGBUS on uncorrected errors, log corrected errors
2: SIGBUS or log uncorrected errors, log corrected errors
3: never panic or SIGBUS, log all errors (for testing only)
Default is 1
Can be also set using sysfs which is preferable.
monarchtimeout:
Sets the time in us to wait for other CPUs on machine checks. 0
to disable.
The mcelog is loging to message by default but you want to check this HW issue separately, audit the /etc/mcelog/mcelog.conf as bellow.
Before:
/usr/sbin/mcelog –ignorenodev –syslog –foreground
After：
/usr/sbin/mcelog –ignorenodev –syslog –foreground –logfile=/var/log/mcelog
Now restart the service
#service mcelog restart
You can find the /var/log/mcelog as expected.
*Background: in the process of updating the schematic to PCB, there is often a mismatch between the components on the schematic and those on the PCB, so we should be very careful and check them one by one, otherwise there will be a lesson of blood and tears (the components in the PCB are lost).
1、 Update the schematic diagram to pcb
II. Perform device matching
There are automatic and manual. For the time being, demonstrate manual operation
for example: C35, find the first column and the second column, then select and click & gt
perform operations similar to C35 one by one
3、 Execute the change
in this figure, the remove operation is to delete the routing
in this figure, the remove operation is to delete the device
Do this carefully. You’d better take a picture, and then check whether any devices are lost one by one Is there any wiring missing!!!
Summary:
(1) this situation is generally caused by the person who changed the drawing before, just for a moment, directly changed the PCB without changing the schematic diagram or updating it
also, the PCB library path corresponding to the device is not specified.
(2) If a lot of network nodes are gone and the routing is gone as soon as the update is executed, it is the layout engineer’s method of drawing lines without nodes in pcbdoc!!!
1. Problem description
In the process of serial communication written with MSComm control, when receiving the data sent by the serial port under the message response function OnComm function, in get_ An error reading comm develop error occurs in the input() function. The specific codes are as follows:
void XXXDlg::OnCommMscommLaser()
{
memset(chstrLaser, 0, 1024); //chstrLaseris a global variable.
short i = m_mscomLaser.get_InBufferCount(); // statement 1.
if(m_mscomLaser.get_CommEvent() == 2) // An event value of 2 means there are characters in the receive buffer.
{
/*m_recivedMsg = "";
CString csstr = "";*/
VARIANT InputData = m_mscomLaser.get_Input(); //Statement 2, read buffer.
COleSafeArray csa = InputData; //VARIANT variable is converted to COleSafeArray variable.
//translate to byte class.
DWORD size = csa.GetOneDimSize();
for(long k = 0; k < size; k++)
csa.GetElement(&k, chstrLaser + k);
}
// Further processing of the received data ......
return;
}Each time the function is triggered, the data length of the receive buffer obtained by statement 1 is 30, which means that the receive buffer has data with a length of 30. However, the above error prompt will appear in statement 2, and the code after statement 2 will not be executed.
2.Method exploration
1. At first, I thought it was a data line problem. By changing the data line and making the data line myself, the problem could not be solved.
2. I suspected that there was a problem with the communication equipment. I also changed the equipment for debugging, but the same problem still occurred.
3. Suspected that the communication protocol was not clear.
4. Wait
3. Solution
After many serial port debugging assistants failed, I found that a serial port debugging assistant can communicate normally. I will provide the debugging assistant later. The current problem may be that the code is written incorrectly, and the data cable and equipment are OK.
Through a large number of searches, I found that one solution was to update the serial driver. After trying, I found that it was really possible. After a whole day, I finally solved this problem. I was very excited.
Here is the solution:
1. Download serial driver
My is a USB to 232 data cable, so I downloaded the prolific USB to serial comm port driver. You can download the corresponding driver according to your actual situation. Here I provide the driver that solves my problem: Click to download the serial port driver.
2. Update driver
After downloading the driver, start updating the driver:
a. Click Manage – > Click device manager -> Locate the serial port configured through the MSComm control
b. Right click the serial driver and click Update Driver Software – > Select browse computer for driver software
c. Click Browse to find the downloaded serial driver
d. Click next to solve the above problems after updating.
Recently, we encountered a problem, that is, the printf display of floating-point calls in uCOSII is abnormal, but the support for floating-point calls on bare metal machines is normal. Here are the details.
When calling printf to debug floating-point numbers in UCOS, it is correct in memory, but print data is 0, and other shaping data are normal.
The running result on bare metal is completely normal, that is to say, the problem lies in UCOS.
According to the information, this is because the user task stack is not aligned with octets. When running bare metal programs, the system’s default stack octets are aligned, but UCOS’s user task stack is not.
Align the user stack octets.
Solution:
1. Solutions under IAR: (untested)
Through # pragma data_ Alignment specifies the number of bytes to align
For example:
#pragma data_alignment=8
OS_STK Task1_LED1_Stk[Task1_LED1_Stk_Size];
#pragma data_alignment=8
OS_STK T
2. Solutions under keil MDK: (available for personal testing)
Add the force octet alignment command before the task stack declaration, as follows:
__align(8) static OS_STK TaskEquipmentStk[TASK_EQUIPMENT_STK_SIZE];
__align(8) static OS_STK TaskUartRcvStk[TASK_UARTRCV_STK_SIZE];
__align(8) static OS_STK TaskFileRcvStk[TASK_FILERCV_STK_SIZE];
__align(8) static OS_STK TaskFtpStk[ TASK_FTP_STK_SIZE ];
__align(8) static OS_STK TaskErrorRateRS485Stk[ TASK_ERROR_RATE_RS485_STK_SIZE ];
Detailed explanation of the reasons
The history of this is that arm itself does not support non aligned data access; Therefore, with a 64bit data operation instruction, the instruction requires 8-byte alignment.
Furthermore, after a certain version of the compiler (rvct3?) AAPCs requires stack 8-byte alignment.
AAPCs with 8-byte alignment first, then cm3. Pay attention to the sequence. Before cm3 r2p0, automatic stack pressing does not require 8 alignment, and r2p0 seems to be forced alignment.
Printf’s 8-alignment is required by the C runtime and has nothing to do with hardware. The C RTL manual is written and can be read. Its root lies in the requirements of AAPCs; AAPCs is rooted in instructions like LDRD.
In other words, in the future, if 128bit data operation is available and arm does not support non alignment, AAPCs may be upgraded to 16 byte alignment.
UART, SPI, IIC and their differences and connections
UART: full duplex asynchronous serial
I2C: half duplex synchronous serial
SPI: full duplex synchronous serial
Bus synchronous or asynchronous: See if there is a clock line
The bus is serial or parallel: bit by bit transmission on the communication line is serial, and multiple data bits are parallel
1) simplex data transmission only supports data transmission in one direction; Only one party can receive or send a message at the same time, such as television or radio.
2) half duplex data transmission allows data to be transmitted in two directions, but, at a certain time, only data is allowed to be transmitted in one direction. It is actually a simplex communication with direction switching; Only one party can receive or send messages at the same time. Two-way communication can be realized. Example: Walkie-talkie.
3) full-duplex data communication allows data to be transmitted in two directions at the same time. Therefore, full-duplex communication is the combination of two simplex communication modes. It requires sending equipment and receiving equipment to have independent receiving and sending capabilities. At the same time, information can be received and sent at the same time, realizing two-way communication, for example: telephone communication.
After inquiring multiple solutions, I guessed that it might be module selection error
, what to reconnect, etc., all of which were invalid.
solution: tools – “development board -” select arduino Uno Wifi- “re-upload 