- Wed Sep 02, 2020 12:35 pm
#88642
Until today I was using commit b77cb8c18b0023483045020433f2b44090df556a of the NONOS-SDK. It's fairly recent, has a reasonable amount of IRAM left and works well enough. I had been trying newer commits, but that takes away yet another chunk of our precious IRAM, so I wasn't too enthousiastic and reverted to above commit.
Now I am having a few interesting association issue, so I though let's have a go at it and try the newest commit: be2f86d30c46267ae4fed66f08138c1881eb71c1. It has the less IRAM "feature" but also another very interesting feature which I don't quite like: apparently the stack has moved! I am using a very handy stack painting feature to measure actual stack usage. I can't use that anymore and I haven't got a clue where the stack is now and how big it is...
Before, the stack would start at 0x3fffeb30 (stack top) and finish at 0x40000000 (stack bottom), which makes atbout 5200 bytes, which is really quite a bit of space.
Now, at any of the pre_init, user_init and user_init2, I see the stack pointer being outside that area, it's at 0x3fffea80 now, 5500 bytes below the stack bottom. It can't be they only enlarged the stack area, because the SP being there, all of the 5500 bytes would already be in use, which is impossible at this point.
Now when I am called back, by a timer or lwip, I see the stack pointer again in the usual area.
I don't understand anything of it. I am very sure I am going to stick to the "old" commit for some time until I know what is going on here.
Anyone an idea? Maybe a way to bring the NONOS and RTOS memory layouts more in line with each other? But then I still don't understand why the stack pointer is in such a different area between init functions and callback!
Now I am having a few interesting association issue, so I though let's have a go at it and try the newest commit: be2f86d30c46267ae4fed66f08138c1881eb71c1. It has the less IRAM "feature" but also another very interesting feature which I don't quite like: apparently the stack has moved! I am using a very handy stack painting feature to measure actual stack usage. I can't use that anymore and I haven't got a clue where the stack is now and how big it is...
Before, the stack would start at 0x3fffeb30 (stack top) and finish at 0x40000000 (stack bottom), which makes atbout 5200 bytes, which is really quite a bit of space.
Now, at any of the pre_init, user_init and user_init2, I see the stack pointer being outside that area, it's at 0x3fffea80 now, 5500 bytes below the stack bottom. It can't be they only enlarged the stack area, because the SP being there, all of the 5500 bytes would already be in use, which is impossible at this point.
Now when I am called back, by a timer or lwip, I see the stack pointer again in the usual area.
I don't understand anything of it. I am very sure I am going to stick to the "old" commit for some time until I know what is going on here.
Anyone an idea? Maybe a way to bring the NONOS and RTOS memory layouts more in line with each other? But then I still don't understand why the stack pointer is in such a different area between init functions and callback!
