Recently, there are various strange problems in debugging HC32F460. The program continues to crash from different positions, such as increasing the stack size (note, it is increased, and the increase is large enough), modifying some irrelevant code, adding a thread that does nothing, etc., which will lead to various exceptions of the program. Moreover, the debugging can not find the cause, which is the same as memory overflow, The memory has changed for no reason, but it is certain that the memory has not overflowed, and some memory can not be modified. After modification, they have recovered. There are 10000 Cao NIMA in their heart, and such a single chip microcomputer.

However, after two days of debugging, it was suspected that it might be a memory problem. Previously, it was found that HC32 could not use the alignment access of 1,2,1, while other MCU did not affect it. With the doubt test, SRAMH and SRAM3 were shielded (not allowed to be used by the compiler)

	
LR_IROM1 0x0010000 (416*1024)  {    ; load region size_region
  ER_IROM1 0x0010000 (416*1024)  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
   .ANY (+XO)
  }
  

  RW_IRAM3 0x20020000 (28*1024)  {  ; RW data SRAM3 28KB support ECC
  ; .ANY (+RW +ZI)
   .ANY (IRAM3)
  }
  
  RW_IRAM2 0x20010000 (64*1024)  {  ; RW data SRAM2 64KB
   .ANY (+RW +ZI)
   .ANY (IRAM2)
  }
  
  RW_IRAM1 0x20000000 (64*1024)  {  ; RW data SRAM1 64KB
   .ANY (+RW +ZI)
   .ANY (IRAM1)
  }
  
  
  ;SRAMH Memory, high speed memory;
  RW_IRAMH 0x1FFF8000 (32*1024)  {
  ; .ANY (+RW +ZI)
   .ANY (SRAMH)
  }
  ;Ret_SRAM Power down hold SRAM 4KB
  RW_IRAM4 0x200F0000 (4*1024)  {
   .ANY (Ret_SRAM)
  }
}

Note that neither SRAMH nor IRAM3 has been used. At this time, the program miraculously works normally. It has been tested for a long time (SRAMH and IRAM3 have not been turned on before). It has only been turned on recently. There are various strange problems. Find the data with questions (in fact, through the 2-day test, it is found that if the allocated memory space of UCOS is IRAM3 or SRAMH, there is a high probability of problems).

Sure enough, it was found that SRAM3 cannot be directly used as a stack, and the wait delay must be set to 1. OK, this problem was found. Shield SRAM3 separately to enable SRAMH to continue testing, and there will still be irregular reset. Note that it is a direct reset, not a reset in a hardware outage. At this time, I suspect that SRAMH and SRAM1 cannot be accessed directly across regions, Continue the test with questions.

RW_IRAMH 0x1FFF8000 (32*1024-8)  {
   .ANY (+RW +ZI)
   .ANY (SRAMH)
  }
  ;Ret_SRAM Power down hold SRAM 4KB
  RW_IRAM4 0x200F0000 (4*1024)  {
   .ANY (Ret_SRAM)
  }

  8 bytes are intentionally removed from SRAMH to make the memory discontinuous, so as to avoid continuous memory allocation and continue the test.

After more than one hour of testing, the program is very stable. Now take the initiative to write a test code for testing, and the results are as follows:

  Through the test, it is found that if SRAMH and SRAM1 are 32bit aligned during continuous access, there is no problem. In case of non aligned access, I'm sorry. I don't know how to generate this value. Sure enough, some pits still need to be avoided by myself.

  Domestic MCU has a long way to go. If we don't tell these details, we will kill the developers. Today we added a u16 a; As a result, the program is abnormal. A variable is changed tomorrow. As a result, the program is abnormal, but no reason can be found, and an unexecuted code will affect the previously executed code (the memory allocation order has changed). The SRAMH in the document can be executed at the highest speed, but the access cycle can be set, and it is drunk not to tell how to set it.

Well, the above is the pit I recently encountered. Please detour. The following is the final solution.

; V6: armclang
#! armclang --target=arm-arm-none-eabi -mcpu=cortex-m4 -E -x c
;Used ARM V6 Macro definition settings cannot be used after the compiler ROM The starting address and size need to be modified manually
; V5: armcc
;#! armcc -E
#include "BaseSetting.h"

	
LR_IROM1 0x0010000 (416*1024)  {    ; load region size_region
  ER_IROM1 0x0010000 (416*1024)  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
   .ANY (+XO)
  }
  
  ;If used IRAM3 As a stack, you need to set at least 1 read / write wait cycle,This memory is not used as a stack here. It is used for user-defined memory areas
  RW_IRAM3 0x20020000 (28*1024)  {  ; RW data SRAM3 28KB support ECC
  ; .ANY (+RW +ZI)
   .ANY (IRAM3)
  }
  
  RW_IRAM2 0x20010000 (64*1024)  {  ; RW data SRAM2 64KB
   .ANY (+RW +ZI)
   .ANY (IRAM2)
  }
  
  RW_IRAM1 0x20000000 (64*1024)  {  ; RW data SRAM1 64KB
   .ANY (+RW +ZI)
   .ANY (IRAM1)
  }
  
  
  ;SRAMH Memory, high speed memory; Do not use SRAMH As the code execution area, and then deliberately give 8 bytes less to avoid conflict with IRAM1 Continuity also avoids possible non aligned cross region access exceptions
  RW_IRAMH 0x1FFF8000 (32*1024-8)  {
   .ANY (+RW +ZI)
   .ANY (SRAMH)
  }
  ;Ret_SRAM Power down hold SRAM 4KB
  RW_IRAM4 0x200F0000 (4*1024)  {
   .ANY (Ret_SRAM)
  }
}