0

I have a project with an infineon/cypress psoc62 (CY8C624AAZI-S2D44). It is a dual core arm MCU (CM4 is Arm7 and CM0p is Arm6) . I'm using the CM4 core. The CM0p core releases the CM4 from reset and put itself to sleep. The MCU has two SD(Secure Digital)/eMMC peripherals (SDHC0 and SDHC1). I'm trying to use SDHC1 to see "activity" in the clk and cmd pins. SD specs are rather complex and I'm just trying to see what command is sending out to init the eMMC. I do not have an eMMC or SD card installed in my board yet. I'm using SDHC1 with base address 0x40470000. The autogenerated code for modustoolbox is throwing a "hardfault" according to the xPSR register (3 in lower bits) when trying to read address 0x4047152C. It looks like trying to read any register in that range generates a hardfault. I'm trying to learn about arm because I've never used them before. I'm using an empty dual core project so my code is very minimal. Basically I'm writting what in their PDL (Peripheral Device Library) example up to "Configure SD Host". I did not include the optional interrupt code. There is a macro (read-modify-write thingy) inside "(void) Cy_SD_Host_Init(SDHC1, &sdHostConfig, &sdHostContext);" that is throwing the hardfault.

The disassembly window showed me the code that it was generating for the macro that is throwing the hardfault. I found a simulator but it kept complaining about the value #1324. Immediate value loading looked really weird until I found an explanation and calculator here.

So I thought I found a bug in the autogenerated assembly code (picture below). But when I change it so the simulator didn't complaint ...I still get the hardfault when reading address 0x4047152C in modustoolbox. Oddly enough saving the value at that address works. I don't see any memory/peripheral protection code and from what I've read the peripheral memory at 0x40470000 doesn't have any restriction as default.

What else can I do or look into to try to figure out what's causing this hardfault?

Thanks

Assembly code of macro


My assembly code

Rodo
  • 875
  • 4
  • 15
  • A common cause for Hardfault when accessing IO-Space is misalignment. Check your Datasheet if 16Bit access is allowed to this region. If not, use a 32Bit access. You can force this with the -mno-unaligned-access flag in arm-gcc compiler. – ElectronicsStudent Mar 14 '23 at 22:13
  • @ElectronicsStudent: The register technical manual (link below) shows that register 0x4047152C is 16 bit: https://www.infineon.com/dgdl/Infineon-PSoC_6_MCU_CY8C62x8_CY8C62xA_Registers_Technical_Reference_Manual-AdditionalTechnicalInformation-v06_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0f94f764027c&utm_source=cypress&utm_medium=referral&utm_campaign=202110_globe_en_all_integration-files – Rodo Mar 15 '23 at 00:40
  • 1
    Do all accesses to the SDHC1 module's registers result in a HardFault? If so then the problem is likely that you have not enabled the clock to that module. – brhans Mar 15 '23 at 01:48
  • @brhans: I think all accesses to the SDHC1 module's registers result in a HardFault because when I try to look at them in the Register window I get a bunch of errors from the debugger telling me that it can't access memory location 0x4047.... But the clock source **is** set and enabled. – Rodo Mar 15 '23 at 05:25
  • 1
    @Rodo It had a very quick read and came up with a checklist - maybe four eyes see more than two. SDHC0_WRAP_CTL Enable is set? SDHC0_CORE_CLK_CTRL_R Clock enabled and stable? But as i said: Quick read, no knowledge about the controller - just guessing and trying to help. – ElectronicsStudent Mar 15 '23 at 08:42
  • @ElectronicsStudent: SDHC0_WRAP_CTL was disabled. I enabled it and the hardfault went away!!. Thanks. You should put that comment in an answer.... thanks again. – Rodo Mar 15 '23 at 21:52
  • @Rodo Glad to help! – ElectronicsStudent Mar 15 '23 at 22:51

1 Answers1

2

After a quick look at the technical register description See here

i guessed, that the enable bit for the peripheral should be set.

Please see: Bit 31 in 0x40460000 - Page 1634

@Rodo confirmed, that the error was fixed.

ElectronicsStudent
  • 2,746
  • 5
  • 18