cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 MCU unable to communicate with DPRAM

Aarra.1
Senior

Hello,

I'm working on my customized board with STM32H747XIH6 MCU which is connected to the DPRAM (Part No: 70T653MS12BCGI). The connectivity is as follows.

0693W00000Y9RPbQAN.pngWhile I'm trying to read and write from the DPRAM after 22 locations the software hangs

I have attached my code snippet hardware configuration file and console message below for your reference.

uint8_t MemCheck(uint32_t startAdd, uint32_t endAdd)
{
	uint8_t  jCount = 0;
	uint32_t iCnt = 0;
	uint32_t Data = 0;
	uint32_t  AddRange  = 0;
	unsigned int addout = 0;
	AddRange = (endAdd - startAdd)/4;
	for(jCount = 0; jCount < 4; jCount++)
	{
		for(iCnt = 0; iCnt < AddRange; iCnt++)
		{
			addout = startAdd;
 
			addout = startAdd+(iCnt*4);
			*(uint32_t*) (addout) = addout; 
		}
		for(iCnt = 0; iCnt < AddRange; iCnt++)
		{
			addout = startAdd+(iCnt*4);
			Data = *(uint32_t*)(addout);
			if(Data != addout) 
			{
				return 0xFF;		//Test Failed
			}
		}
	}
	return 0x00;
}

Console Message :

handle_vCont_t, Failed halting thread

handle_vCont_t, Failed halting thread

Kindly help me figure out the issue as to where is the fault I'm not able to detect the DPRAM.

1 ACCEPTED SOLUTION

Accepted Solutions

Finally The issue has been solved.

Under the SRAM configuration : 

I disabled the wait (Previously it was in asynchronous mode)

and also disabled the Byte enable (Previously it was 32- bit Byte enable)

Though I still don't understand how the asynchronous mode would effect here.

If someone could explain me that it would be great help.

Thank you all for your help and time.

View solution in original post

7 REPLIES 7
Javier1
Principal

>>customized board with STM32H747XIH6 MCU.

Did you rule out issues in the PCB trace layout?

Does it matter which 22 locations you read?

Aarra.1
Senior

Hello Javier,

Thank you for your response.

>>Did you rule out issues in the PCB trace layout?

Yes we have worked that out.

>>Does it matter which 22 locations you read?

As we have tried reading and writing to different locations and in the code provided above we can provide a range of addresses.

We are able to read and write from any 22 locations while performing the 23rd write/read operation the software gets stuck.

While debugging when I open the Memory debug window the code stops working and it prints "Target lost connection" in the console.

Aarra.1
Senior

Hello,

I'm still stuck with this issue kindly help me to solve the same.

Thank you

>>We are able to read and write from any 22 locations while performing the 23rd write/read operation the software gets stuck.

Understood, does it matter how long does it take you to read those 23 addresses? (adding debugging breaks in between each reading)

>>While debugging when I open the Memory debug window the code stops working and it prints "Target lost connection" in the console.

This is very interesting, how are you debugging the board?

Stlink? you could post your cubeMx file and/or pcb details of the debugging connector

>>Understood, does it matter how long does it take you to read those 23 addresses? (adding debugging breaks in between each reading)

No that doesn't matter as of now as I just want read and write continuously from the DPRAM.

>>This is very interesting, how are you debugging the board?

Yes, I'm using STLINK-V3SET for debugging.

I have attached my CubeMX report file in the beginning of this query.

LCE
Principal

Did you already try a simple looped byte write and read back?

And how have you ensured that the variables are in the external RAM?

Finally The issue has been solved.

Under the SRAM configuration : 

I disabled the wait (Previously it was in asynchronous mode)

and also disabled the Byte enable (Previously it was 32- bit Byte enable)

Though I still don't understand how the asynchronous mode would effect here.

If someone could explain me that it would be great help.

Thank you all for your help and time.