SWD lost when accessing NAND via FMC

[Brian H]

Hello.  I am working with a STM32H563IIKX, connected to an external Macronix MX30LF2G28AD NAND Flash chip.  I have configured the FMC for NAND operation with what I think are correct parameters (this is completely new to me).

I thought I'd try a very simple test to see if communication with the external NAND is working at all.  After all of the auto-generated MX_xxxx_Init() calls in main(), I added this:

NAND_IDTypeDef nandID = { 0 };
HAL_StatusTypeDef nand_rc = HAL_NAND_Read_ID(&hnand1, &nandID);

Once I "step over" the call to HAL_NAND_Read_ID, SWD loses connection ("Target is not responding, retrying..." until it gives up).

If I step into HAL_NAND_Read_ID, SWD is lost specifically at this line:

data = *(__IO uint32_t *)deviceaddress;

Is this expected behavior?  Is SWD somehow incompatible with FMC-NAND?  Or is this possibly just an indication that my NAND parameters (or wiring) is wrong?  What other information should I provide to help diagnose this?

[Tesla DeLorean]

>> What other information should I provide to help diagnose this?

The address it's attempting to read, and the pins you're using for the interface.

Have a HardFault_Handler() that can output to a serial port, independently of the debug interface.

Some of the high order address pins might be involved in the Trace port, but you're not indicating that you're using that, just the SWD so probably PA13, PA14, PB3 involved there.

Is the hnand1 structure fully initialized and within scope?

[Brian H]

Hello Tesla,

>> The address it's trying to read

I am using the HAL_NAND_ functions.  It looks like it's trying to read address 0x8000 0000.  I am assuming that MX is generating correct code for the platform and that that address is correct.  Section 2.3.2 of RM0481 indeed shows FMC Bank 3 located in the 0x8000 0000-0x8FFF FFFF address block.

>> and the pins you're using for the interface

I've attached the .ioc, which should serve as evidence that I don't have any pin assignment conflicts (or prove I didn't realize I had one).  Note that although the MX debug configuration is set to JTAG (4 pins), I have the debug launch configuration set to use SWD due to having NJTRST (not part of 4-wire JTAG) assigned to GPIO, which triggers a known erratum.  This combination of MX settings and launch configuration has been working so far, so I haven't bothered to change the MX setting to Trace Asynchronous Sw.

>> Have a HardFault_Handler() that can output to a serial port, independently of the debug interface.
Can't do that specifically, but I can have the handler wiggle some extra GPIOs I set aside for debugging.  It does not appear that HardFault_Handler is being called, nor is the application continuing to progress.

>> Is the hnand1 structure fully initialized and within scope?

Yes, this is the global struct generated by MX and initialized by the call to MX_FMC_Init() eariler in main().