Hi All,
My target has 128k SRAM which has about 60k spare, and 64k CCM which
is allocated whole to FreeRTOS stacks etc (its private heap, memory
model #4).
I am running a simplified HTTP server (for local config etc), which
uses fairly minimal RAM (a few k), and an HTTPS/TLS client which uses
about 50k (for its private heap).
So if both of the above are running concurrently, there is only ~10k
RAM left, but it does work, but when TLS is doing its
handshake/negotiation (which on a 168MHz 32F417 takes 2-3 seconds) the
HTTP server temporarily hangs.
Investigating this, it appears that LWIP is running out of buffers
during TLS and is rejecting incoming packets.
I don't really want to change the CPU to the next one up which has
another 64k RAM, because a) I have stock of the 417 and this took
about a year to get, b) the design is rock solid and I don't want to
tempt fate (there is a lot of subtle hardware usage e.g. DAC ADC DMA
timers) even though in theory it should be just alternate function pin
changes, c) some versions of the product may not need TLS at all.
I have an option of an 8 megabyte SPI-attached RAM
https://www.eevblog.com/forum/microcontrollers/lyontek-ly68l6400-8-megabyte…
which does work and is not bad at $3 (there are cheaper 128kbyte
versions too), but obviously cannot be addressed as normal RAM. The
ESP32 can do that but the 32F4 can't.
Does anyone know enough about the internals of MbedTLS, or even LWIP,
to know whether the memory usage structure lends itself to this kind
of "overlay" memory? One can read or write say 1k bytes in 400us, in
my target (21MHz SPI with DMA). Obviously this would be horribly
inefficient for a byte at a time emulation but perhaps one can switch
buffers in and out...
Thank you in advance. If somebody knows of a concrete route, I am
happy to pay for the time.
Regards,
Peter
