UCD3138: UCD device doesn't work after RAM size exceeds 88%

Ender Türkyilmaz

Part Number: UCD3138

Hello,

I have been working on my PMBus project. To speed up status read/write operations in status registers, I have applied my custom Get/Set functions by using RAM. I noticed that after RAM's memory allocation rate is reached to 88%, device doesn't allow me to flash program. Also, FAULT message doesn't appear on GUI when I apply OV or UV cases. What's the reason behind this behavior ? Is there anything I can try to avoid that ?

Best Regards

over 3 years ago

0 Ian Bower over 3 years ago

TI__Genius 17090 points

I'm not sure how you are using the RAM or measuring the memory allocation. I suspect that you are running into the stack, although you may be running into the variables. I don't know what you mean by the device not allowing you to flash program. I will give you guidance on how to avoid running into stack and variables. If that doesn't solve it, please give me more information on what you mean by not allowing you to flash program.

As far as the OV or UV cases, in general you need to debug through the signal chain to the PMBus command. the OV/UV start with either an ADC reading or a comparator trigger, so you can just start looking along the chain from the ADC or comparator through to the PMBus command and see where it is breaking down.

For RAM, there is typically a bit of a disconnect between the load.asm file and the .cmd file. The load.asm file will have the stack pointer addresses defined like this:

SUP_STACK_TOP .equ 0x19ffc ;Supervisor mode (SWI stack) starts at top of memory
FIQ_STACK_TOP .equ 0x19e00 ;allocate 256 bytes to supervisor stack, then do FIQ stack
IRQ_STACK_TOP .equ 0x19d00 ;allocate 256 bytes to fiq stack, then start irq stack
USER_STACK_TOP .equ 0x19b00 ;Allocate 512 bytes to irq stack, regular stack gets rest, down to variables

So the lowest address - USER_STACK_TOP, will define the top of the user stack, which will expand down from there. It's relatively easy to figure out how much stack you are using. load.asm also clears all the RAM. So you can use the memory debugger to look at the stack locations and see how much is being used. You can then adjust the stack locations, since our normal stack allocation is very generous.

There's also typically a .cmd file, called cyclone.cmd, or sometimes cyclone64.cmd or something.

It will have statements like this:

RAM (RW) : org = 0x0001901C, len = 0x00000E50
STACKS (RW) : org = 0x00019E6C, len = 0x00000190

You need to change the RAM size so that it ends before the stack size you have measured above, and then put the stack start where you have measured, and the length to either the next RAM element or the end of the RAM.

This way, at least if your variables fit into the memory below the stack, you should be OK. If you are using some kind of freeform heap sort of thing, you need to either define an array in the variables to hold it. or make it's own RAM area defined in the .cmd file and make sure it stays in that area.

0 Ender Türkyilmaz over 3 years ago in reply to Ian Bower

Prodigy 40 points

Thank you for detailed explanation.

I'm using CCS tools to measure memory allocation. I don't think stack is problem here. Let me show you how I can't flash my program:

1-) As I said, this is from CCS memory allocation tool:

RAM's memory allocation is 86% and I can flash my program to UCD:

2-) When I declare uint32_t array[80] variable as global, you can see that I have still RAM memory enough (95%):

However, I can't flash program to device at this point. WatchDog reset may cause that:

I forgot to mention that I develop my project with C++ on UCD3138. Somehow C++ objects may allocate more RAM space than it seems on CCS memory tool. I tried to increase RAM size as you suggested. STACK size was 0x00000190 which is 400 bytes and I decreased it to 200 bytes which is C8:

Before:

    RAM_PGM_AREA	(RW) : org = 0x00019000, len = 0x00000080
	RAM       		(RW) : org = 0x00019080, len = 0x00000DF0
	STACKS    		(RW) : org = 0x00019E70, len = 0x00000190

After:

    RAM_PGM_AREA	(RW) : org = 0x00019000, len = 0x00000080
	RAM       		(RW) : org = 0x00019080, len = 0x00000EB8
	STACKS    		(RW) : org = 0x00019F38, len = 0x000000C8

At his point compiler didn't give any error or warning, but I couldn't flash my program to UCD device:

Briefly, my RAM size may be overflowed after 88% and CCS memory allocation tools may not show the real allocation rate due to C++.
What do you think about it ? Is there any other way I can try ?

Thank you in advance.

0 Ian Bower over 3 years ago in reply to Ender Türkyilmaz

TI__Genius 17090 points

I really don't recommend C++. It's for processors with more power, more memory, and more code complexity than the UCD. I strongly encourage you to start with one of our EVM codes.

It sounds like you are using the standard initialization program as well, which I'm not familiar with. It used about 4k of code, so I took it out and shrank it and made it much smaller.

If you think it's the watchdog timeout, I'd suggest trying to disable it and see what happens.

Often if the stack and variables collide, the stack will be corrupted, and the processor will end up accessing an illegal address, which will also cause a reset.

0 Ender Türkyilmaz over 3 years ago in reply to Ian Bower

Prodigy 40 points

Yeah, but I preferred C++ because it improved code readability and also both C & C++ cost same in terms of, for example, register related operations.

When I disabled watchdog, I was able to flash UCD. Like you said, the processor probably tries to access an ilegal address that's why RAM was insufficient.

Anyway, I optimised the code and it works properly now. Thanks for your support.

0 Ian Bower over 3 years ago in reply to Ender Türkyilmaz

TI__Genius 17090 points

Okay then, I'll close the thread.

Power management

Power management forum

UCD3138: UCD device doesn't work after RAM size exceeds 88%