External memory access/allocation

In reply to ChrisS:

Now I'm back to SigBus errors in new/malloc/delete/free calls after trying to declare the character buffers like this:

html_resource_type html_resources[27];
void init_html_resources()
{
html_resources[0].name = "index.htm";
html_resources[0].data =
"\x1f\x8b\x08\x08\x2a\x72\x4f\x5a\x02\x03\x69\x6e"....

When I move the heap back to RAM everything works as expected. Any ideas?

In reply to ChrisS:

Hi Chris,

SDRAM is not initialized even if you explicitly initialize these items in the code (it is also not 0-initialized). You need a constant array of data in flash that you can then copy into SDRAM after the boot-up.

Regards

In reply to Renesas Karol:

Hi Karol,
ok, but then the code I showed above should work when I call the init function in one of my thread functions?
Why am I seeing errors in malloc/free calls then when I move the heap to SDRAM?
As far as I can tell the heap was working on SDRAM before I switched the way I filled the html_resource_type array from an initializer list to a separate init function.

In reply to ChrisS:

I think I might have an idea why this happens, if I have some static constructors that use the heap, is the SDRAM initialized at this point?

In reply to ChrisS:

I think I just answered the question myself, SD-RAM initialization is called in bsp_sdram_init, which is called after __init_array_start which calls the static constructors. Is there a reason why SDRAM isn't initialized before? Then this would not be an issue?

In reply to ChrisS:

I just tested this by moving the calls to __init_array_start after the call to bsp_init(NULL) and write-protecting system_S7G2.c and I get no crashes anymore with the heap in SDRAM. Is there a chance we can have this as default behaviour in Synergy, or are there any reasons against this modification?

In reply to ChrisS:

Hello Chris,

SDRAM is board-specific component. BSP files may be using some global variables and flags meaning that bsp_init has to be called after C runtime init (which includes invocation of static constructors). Using heap is generally discouraged in embedded applications but if you require your SDRAM to be initialized asap you can override R_BSP_WarmStart and create a block for BSP_WARM_START_PRE_C argument that initializes SDRAM before the rest of the BSP. Bear in mind that pins, hardware locks and clocks are not yet configured at this point.

Regards

In reply to Renesas Karol:

I think my question was actually the other way around. I would like to call the C++ constructors at the end, after SD-RAM was initialized, not move SD-RAM initialization to an earlier stage.

In reply to ChrisS:

Hi Chris,

As Karol wrote, BSP files may be using global variables, so static constructors should be already called before bsp_init. Fortunately, you may still edit these files and mark them as read-only, if you need to provide any modifications.

Regards,
adboc

In reply to adboc:

Ah ok, I overlooked that and didn't notice any side effects in my project. Looking at the code, I guess it's not possible to separate C++ constructed object initialization from C global variables?

I'm fine with using write protection, just wondering.

In reply to ChrisS:

Hi Chris,

C globals are initialized here:

while C++ static constructors are called later:

I think that Renesas decided to call static constructors before BSP initialization, because custom BSPs might use static C++ objects.

Rgards,
adboc

In reply to adboc:

Hi adboc,
thanks for your explanation! It makes more sense to me now as I didn't see any C++ codein SSP so I thought that __init_array_start also covered C globals.