2020-11-30 07:19 AM
I have developed touchgfx based applications in STM32H745XI devices only in Cortex-M7. It went smooth till few screens. later adding one more screen
has increased the memory as below
Program Size: Code=149192 RO-data=549672 RW-data=8968 ZI-data=159696
and the linker settings as as below
; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************
LR_IROM1 0x08000000 0x00200000 { ; load region size_region
ER_IROM1 0x08000000 0x00200000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
.ANY (+RO)
}
RW_IRAM1 0x24000000 0x00080000{ ; RW data
.ANY (+RW +ZI)
}
}
As per data sheet 0x2400000 AXISRAM has up to 800Kbytes of memory and there is no error for memory overflow. But code is not executing.
I have tried debugging and surprisingly it goes to hard fault. After a few continuous runs in debug mode(ignoring the hard faults) it starts working and if we remove power and plug it back nothing works.
Same code without additional screens below memory footprint is working fine even in debug or run mode.
Program Size: Code=103616 RO-data=596612 RW-data=8816 ZI-data=125072
Regards,
Narendar.v
2020-11-30 08:30 AM
You seem to be commingling several issues here
The AXI RAM at 0x24000000 is 512 KB
Hard Faults are relatively easy to chase to ground, have a HardFault_Handler() that actually outputs actionable data so you can identify what's actually failing.
Devices not starting is most typically due to BOOT0 not being pulled low, or that the device is actually running but dying quietly in Error_Handler() or HardFault_Handler(), both of which could be remediated with some output.
Secondarily the Dual H7 parts are very sensitive to LDO/SMPS and VOS configuration, mess these up and the device will look completely bricked. You'll need to power-cycle the device with BOOT0 HIGH to recover to a point you can erase your broken code.
2020-11-30 11:53 AM
Thanks,
Yes, your write these is problem with memory overflow,how to configure scatter file to match with my memory requirement.
and i am taken care by LDO/SMPS, Lower coding memory application is fine,but my application is greter then 1.5 mb at the time code is compiling without any error,but it is not executing means it gets hard fault.
Regards,
Narendar.v
2020-12-01 10:31 PM
can you plese updated the status,we are in deep troble..
Thanks,
Narendar.v
2020-12-01 11:19 PM
Not sure what I'm supposed to do here.
Lack of build errors means there aren't any syntax errors, not that your code is free of bugs.
Instrument your code/handlers so you can get details of registers and instructions at the site of the fault. Review that code, add sanity checks to catch the failures before they fault. Trace back where the failing values are coming from.
If you are using dynamic memory allocation check that the mallocs don't fail.
2020-12-03 03:12 AM
I have had hard faults happen when a memory buffer was overflowing and corrupting RAM. The scatter file will not catch this kind of behaviour.
If adding one more page to your program causes a hard fault, check that there is enough memory to go around in your buffer and that you're not writing to a memory area currently in use.
You could also try to implement a memory protection area in RAM after the point where you think your program stops using memory. If something overflows, the memory protection unit should catch it.