CC2640R2F: onchip片上oad扩展应用空间

上面的问题已经解决，通过测试可以压缩掉bim的0x1000的空间，但是，压缩之后，进行oad升级的应用app，里面操作snv的时候崩溃了，我确实stack里面的bim大小也修改了，而且宏定义里面有OSAL_SNV=1，请问是哪的配置问题？还少别的配置吗？

再补充一下，这个问题的进展，snv写崩溃，我调用snv写的地方是scs串口收到数据回调里面，我在不带oad的工程中用同样的代码测试过，调用snv接口是没问题的，但是移到oad里面的就不行，我也扩展了scs线程的堆栈大小，仍然不行，后来测试，放到定时器事件里面就可以，请问这是哪的问题？如果是因为write耗时长必须放到定时器事件，那不带oad的工程又为什么会写成功呢？

flash优化参考：https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_5_30_00_03/docs/blestack/ble_user_guide/html/ble-stack-3.x/creating-a-custom-bluetooth-low-energy-application.html#flash-optimization

另外注意，CC2640r2f片上内存很小，只适合做非常小的OAD应用：https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_5_30_00_03/docs/blestack/ble_user_guide/html/oad-secure/flash-layout-on-chip-split-image.html

如果你的应用比较大，那优化flash也没有办法解决，应该使用offchip或者换成更大内存的CC2642R

多谢回复，那我现在snv的问题，串口回调里面去write的话，应该使用的是串口线程的堆栈吧，而放到定时器事件里面用的是从设备蓝牙线程的堆栈，也就是我现在的问题，很有可能是串口线程堆栈虽然分配了不少，但是实际上超了内存最大值了？

看了下map文件，unusd sram还有0x14db，应该还足够吧

SNV占用的应该是flash的空间，不清楚你的程序框架，还新建了一个串口线程？

内存使用及调试可参考：https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_4_30_00_08/docs/blestack/ble_user_guide/html/ble-stack-3.x-guide/debugging-index.html#rov-in-ccs

是的，用的scs来虚拟的串口，创建了一个线程来管理，收到串口数据调snv的write就崩溃了，放到定时器的事件就没事，我感觉这个地方应该跟是不是带oad的工程没啥关系，这应该是个单独的功能吧？不带oad的工程，这样操作就没事，带oad的就不行。我认为是主要的区别也就是内存上，但是看了是没超。别的地方，感觉两个就这个scs串口和snv的write应该没啥差异

嗯，是在任务上下文，也就是线程中使用的，我是用scs模拟的一个串口，里面有个线程来接收数据，收到数据的处理里面调用了svn write，而且这同样的线程处理及snv write处理，放到非oad的demo中是可以使用的，放到oad的线程里面就没法用了，我再想是不是现在这个工程有什么配置会影响这个？但是hwi和swi应该不是，要不然不带oad的例程里面应该也没法用。

另外，想咨询一下，想那些非oad的项目，直接ccs上debug可以仿真，崩溃的时候起码能看到一些信息，但是想oad的这种，我先升级了bim，peristent app和stack，然后通过手机oad升级了最终的app，这种有办法仿真吗？这样我能进一步看到snv write到底崩溃的时候有没有什么有效信息，不像现在这样只能试

yan peter 说：

但是想oad的这种，我先升级了bim，peristent app和stack，然后通过手机oad升级了最终的app，这种有办法仿真吗？

这是另一个问题了，请为此重开一个新帖，以便更有针对性的解决