TI中文支持网controlSUITE3.4.7\device_support\f2833x\v142\DSP2833x_examples_ccsv5\f28335_flash_kernel
这个是TI的官方API例程，我通过仿真器下载到28335中，擦除flash成功。但是我将该API转换为BIN文件，通过串口发送到28335中，擦除FLASH失败，返回24.
具体过程如下：
编译工程生成.out,转换为hex再转换为bin，将28335切换到boot scia模式，通过串口助手发送API，之后API在28335的ram中执行（发送0x41返回0x41），但是执行到擦除flash时失败，返回24。
发生以下两种现象：
1.通过仿真器下载API后，擦除flash成功，此时如果去掉仿真器，保证28335不断电，进入boot scia模式，串口助手发送api，擦除flash成功。
2.一旦28335重新上电后，串口助手发送api，擦除flash每次失败，返回24.
排除hex转bin时错误，因为该转换工具用了比较久了，28062 api和其他dsp程序都是通过同样方式转换的，一直都是正常的；
排除28335硬件问题（如供电问题、芯片问题等），因为使用C2Prog来烧写，同样也是SCI方式，擦除flash每次都正常。
该问题卡了一段时间了，网上查找该问题，都是2014年前的，且没有留下正确详细的解决方式。
不知道为什么会这样，仿真器烧写后不断电发送API成功，重新上电后就不成功；TI例程的API与C2Prog的API又有什么区别呢？我又该如何解决我的问题？
手上有28335的大神能否帮忙测试一下TI的API在你们这是否是正常的？
希望得到TI工程师或各路大神的指点与帮助。
Seven Han：
请参考这边帖子：http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/640664
controlSUITE3.4.7\device_support\f2833x\v142\DSP2833x_examples_ccsv5\f28335_flash_kernel
这个是TI的官方API例程，我通过仿真器下载到28335中，擦除flash成功。但是我将该API转换为BIN文件，通过串口发送到28335中，擦除FLASH失败，返回24.
具体过程如下：
编译工程生成.out,转换为hex再转换为bin，将28335切换到boot scia模式，通过串口助手发送API，之后API在28335的ram中执行（发送0x41返回0x41），但是执行到擦除flash时失败，返回24。
发生以下两种现象：
1.通过仿真器下载API后，擦除flash成功，此时如果去掉仿真器，保证28335不断电，进入boot scia模式，串口助手发送api，擦除flash成功。
2.一旦28335重新上电后，串口助手发送api，擦除flash每次失败，返回24.
排除hex转bin时错误，因为该转换工具用了比较久了，28062 api和其他dsp程序都是通过同样方式转换的，一直都是正常的；
排除28335硬件问题（如供电问题、芯片问题等），因为使用C2Prog来烧写，同样也是SCI方式，擦除flash每次都正常。
该问题卡了一段时间了，网上查找该问题，都是2014年前的，且没有留下正确详细的解决方式。
不知道为什么会这样，仿真器烧写后不断电发送API成功，重新上电后就不成功；TI例程的API与C2Prog的API又有什么区别呢？我又该如何解决我的问题？
手上有28335的大神能否帮忙测试一下TI的API在你们这是否是正常的？
希望得到TI工程师或各路大神的指点与帮助。
mangui zhang：
在线的时候操作正常 此时应该在RAM中操作的
烧写后加载 可能受到保护或其他原因
controlSUITE3.4.7\device_support\f2833x\v142\DSP2833x_examples_ccsv5\f28335_flash_kernel
这个是TI的官方API例程，我通过仿真器下载到28335中，擦除flash成功。但是我将该API转换为BIN文件，通过串口发送到28335中，擦除FLASH失败，返回24.
具体过程如下：
编译工程生成.out,转换为hex再转换为bin，将28335切换到boot scia模式，通过串口助手发送API，之后API在28335的ram中执行（发送0x41返回0x41），但是执行到擦除flash时失败，返回24。
发生以下两种现象：
1.通过仿真器下载API后，擦除flash成功，此时如果去掉仿真器，保证28335不断电，进入boot scia模式，串口助手发送api，擦除flash成功。
2.一旦28335重新上电后，串口助手发送api，擦除flash每次失败，返回24.
排除hex转bin时错误，因为该转换工具用了比较久了，28062 api和其他dsp程序都是通过同样方式转换的，一直都是正常的；
排除28335硬件问题（如供电问题、芯片问题等），因为使用C2Prog来烧写，同样也是SCI方式，擦除flash每次都正常。
该问题卡了一段时间了，网上查找该问题，都是2014年前的，且没有留下正确详细的解决方式。
不知道为什么会这样，仿真器烧写后不断电发送API成功，重新上电后就不成功；TI例程的API与C2Prog的API又有什么区别呢？我又该如何解决我的问题？
手上有28335的大神能否帮忙测试一下TI的API在你们这是否是正常的？
希望得到TI工程师或各路大神的指点与帮助。
feiyu yu：
回复 Seven Han:
Seven Han
请参考这边帖子：http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/640664
controlSUITE3.4.7\device_support\f2833x\v142\DSP2833x_examples_ccsv5\f28335_flash_kernel
这个是TI的官方API例程，我通过仿真器下载到28335中，擦除flash成功。但是我将该API转换为BIN文件，通过串口发送到28335中，擦除FLASH失败，返回24.
具体过程如下：
编译工程生成.out,转换为hex再转换为bin，将28335切换到boot scia模式，通过串口助手发送API，之后API在28335的ram中执行（发送0x41返回0x41），但是执行到擦除flash时失败，返回24。
发生以下两种现象：
1.通过仿真器下载API后，擦除flash成功，此时如果去掉仿真器，保证28335不断电，进入boot scia模式，串口助手发送api，擦除flash成功。
2.一旦28335重新上电后，串口助手发送api，擦除flash每次失败，返回24.
排除hex转bin时错误，因为该转换工具用了比较久了，28062 api和其他dsp程序都是通过同样方式转换的，一直都是正常的；
排除28335硬件问题（如供电问题、芯片问题等），因为使用C2Prog来烧写，同样也是SCI方式，擦除flash每次都正常。
该问题卡了一段时间了，网上查找该问题，都是2014年前的，且没有留下正确详细的解决方式。
不知道为什么会这样，仿真器烧写后不断电发送API成功，重新上电后就不成功；TI例程的API与C2Prog的API又有什么区别呢？我又该如何解决我的问题？
手上有28335的大神能否帮忙测试一下TI的API在你们这是否是正常的？
希望得到TI工程师或各路大神的指点与帮助。
feiyu yu：
回复 mangui zhang:
mangui zhang
在线的时候操作正常 此时应该在RAM中操作的
烧写后加载 可能受到保护或其他原因
controlSUITE3.4.7\device_support\f2833x\v142\DSP2833x_examples_ccsv5\f28335_flash_kernel
这个是TI的官方API例程，我通过仿真器下载到28335中，擦除flash成功。但是我将该API转换为BIN文件，通过串口发送到28335中，擦除FLASH失败，返回24.
具体过程如下：
编译工程生成.out,转换为hex再转换为bin，将28335切换到boot scia模式，通过串口助手发送API，之后API在28335的ram中执行（发送0x41返回0x41），但是执行到擦除flash时失败，返回24。
发生以下两种现象：
1.通过仿真器下载API后，擦除flash成功，此时如果去掉仿真器，保证28335不断电，进入boot scia模式，串口助手发送api，擦除flash成功。
2.一旦28335重新上电后，串口助手发送api，擦除flash每次失败，返回24.
排除hex转bin时错误，因为该转换工具用了比较久了，28062 api和其他dsp程序都是通过同样方式转换的，一直都是正常的；
排除28335硬件问题（如供电问题、芯片问题等），因为使用C2Prog来烧写，同样也是SCI方式，擦除flash每次都正常。
该问题卡了一段时间了，网上查找该问题，都是2014年前的，且没有留下正确详细的解决方式。
不知道为什么会这样，仿真器烧写后不断电发送API成功，重新上电后就不成功；TI例程的API与C2Prog的API又有什么区别呢？我又该如何解决我的问题？
手上有28335的大神能否帮忙测试一下TI的API在你们这是否是正常的？
希望得到TI工程师或各路大神的指点与帮助。
Seven Han：
回复 feiyu yu:
芯片应该是没有问题，关于flashapi的使用要求在手册中有给出：controlSUITE_Flash2833x_API_Readme.pdf
API Don’ts: Don’t execute the Flash APIs from the flash or OTP. If the APIs are stored in flash or OTP memory,they must first be copied to internal SARAM before they are executed. Don’t execute any interrupt service routines (ISRs) that can occur during an erase, program ordepletion recovery API function from the flash or OTP memory blocks. Until the API function completesand exits the flash and OTP are not available for program execution or data storage. Don’t execute the API callback function from flash or OTP. When the callback function is invoked bythe API during the erase, program or depletion recovery routine the flash and OTP are not available forprogram execution or data storage. Only after the API function completes and exits will the flash andOTP be available. Don’t stop the erase, program or depletion recovery functions while they are executing (for example,don’t stop the debugger within API code, don’t reset the part, etc). Do not execute code or fetch data from the flash array or OTP while the flash and/or OTP is beingerased, programmed or during depletion recovery.
controlSUITE3.4.7\device_support\f2833x\v142\DSP2833x_examples_ccsv5\f28335_flash_kernel
这个是TI的官方API例程，我通过仿真器下载到28335中，擦除flash成功。但是我将该API转换为BIN文件，通过串口发送到28335中，擦除FLASH失败，返回24.
具体过程如下：
编译工程生成.out,转换为hex再转换为bin，将28335切换到boot scia模式，通过串口助手发送API，之后API在28335的ram中执行（发送0x41返回0x41），但是执行到擦除flash时失败，返回24。
发生以下两种现象：
1.通过仿真器下载API后，擦除flash成功，此时如果去掉仿真器，保证28335不断电，进入boot scia模式，串口助手发送api，擦除flash成功。
2.一旦28335重新上电后，串口助手发送api，擦除flash每次失败，返回24.
排除hex转bin时错误，因为该转换工具用了比较久了，28062 api和其他dsp程序都是通过同样方式转换的，一直都是正常的；
排除28335硬件问题（如供电问题、芯片问题等），因为使用C2Prog来烧写，同样也是SCI方式，擦除flash每次都正常。
该问题卡了一段时间了，网上查找该问题，都是2014年前的，且没有留下正确详细的解决方式。
不知道为什么会这样，仿真器烧写后不断电发送API成功，重新上电后就不成功；TI例程的API与C2Prog的API又有什么区别呢？我又该如何解决我的问题？
手上有28335的大神能否帮忙测试一下TI的API在你们这是否是正常的？
希望得到TI工程师或各路大神的指点与帮助。
feiyu yu：
回复 Seven Han:
Seven Han
芯片应该是没有问题，关于flashapi��使用要求在手册中有给出：controlSUITE_Flash2833x_API_Readme.pdf
API Don’ts: Don’t execute the Flash APIs from the flash or OTP. If the APIs are stored in flash or OTP memory,they must first be copied to internal SARAM before they are executed. Don’t execute any interrupt service routines (ISRs) that can occur during an erase, program ordepletion recovery API function from the flash or OTP memory blocks. Until the API function completesand exits the flash and OTP are not available for program execution or data storage. Don’t execute the API callback function from flash or OTP. When the callback function is invoked bythe API during the erase, program or depletion recovery routine the flash and OTP are not available forprogram execution or data storage. Only after the API function completes and exits will the flash andOTP be available. Don’t stop the erase, program or depletion recovery functions while they are executing (for example,don’t stop the debugger within API code, don’t reset the part, etc). Do not execute code or fetch data from the flash array or OTP while the flash and/or OTP is beingerased, programmed or during depletion recovery.
controlSUITE3.4.7\device_support\f2833x\v142\DSP2833x_examples_ccsv5\f28335_flash_kernel
这个是TI的官方API例程，我通过仿真器下载到28335中，擦除flash成功。但是我将该API转换为BIN文件，通过串口发送到28335中，擦除FLASH失败，返回24.
具体过程如下：
编译工程生成.out,转换为hex再转换为bin，将28335切换到boot scia模式，通过串口助手发送API，之后API在28335的ram中执行（发送0x41返回0x41），但是执行到擦除flash时失败，返回24。
发生以下两种现象：
1.通过仿真器下载API后，擦除flash成功，此时如果去掉仿真器，保证28335不断电，进入boot scia模式，串口助手发送api，擦除flash成功。
2.一旦28335重新上电后，串口助手发送api，擦除flash每次失败，返回24.
排除hex转bin时错误，因为该转换工具用了比较久了，28062 api和其他dsp程序都是通过同样方式转换的，一直都是正常的；
排除28335硬件问题（如供电问题、芯片问题等），因为使用C2Prog来烧写，同样也是SCI方式，擦除flash每次都正常。
该问题卡了一段时间了，网上查找该问题，都是2014年前的，且没有留下正确详细的解决方式。
不知道为什么会这样，仿真器烧写后不断电发送API成功，重新上电后就不成功；TI例程的API与C2Prog的API又有什么区别呢？我又该如何解决我的问题？
手上有28335的大神能否帮忙测试一下TI的API在你们这是否是正常的？
希望得到TI工程师或各路大神的指点与帮助。
feiyu yu：
问题已解决，
controlSUITE3.4.7\device_support\f2833x\v142\DSP2833x_examples_ccsv5\f28335_flash_kernel
这个是TI的官方API例程，我通过仿真器下载到28335中，擦除flash成功。但是我将该API转换为BIN文件，通过串口发送到28335中，擦除FLASH失败，返回24.
具体过程如下：
编译工程生成.out,转换为hex再转换为bin，将28335切换到boot scia模式，通过串口助手发送API，之后API在28335的ram中执行（发送0x41返回0x41），但是执行到擦除flash时失败，返回24。
发生以下两种现象：
1.通过仿真器下载API后，擦除flash成功，此时如果去掉仿真器，保证28335不断电，进入boot scia模式，串口助手发送api，擦除flash成功。
2.一旦28335重新上电后，串口助手发送api，擦除flash每次失败，返回24.
排除hex转bin时错误，因为该转换工具用了比较久了，28062 api和其他dsp程序都是通过同样方式转换的，一直都是正常的；
排除28335硬件问题（如供电问题、芯片问题等），因为使用C2Prog来烧写，同样也是SCI方式，擦除flash每次都正常。
该问题卡了一段时间了，网上查找该问题，都是2014年前的，且没有留下正确详细的解决方式。
不知道为什么会这样，仿真器烧写后不断电发送API成功，重新上电后就不成功；TI例程的API与C2Prog的API又有什么区别呢？我又该如何解决我的问题？
手上有28335的大神能否帮忙测试一下TI的API在你们这是否是正常的？
希望得到TI工程师或各路大神的指点与帮助。
feiyu yu：
问题已解决
controlSUITE3.4.7\device_support\f2833x\v142\DSP2833x_examples_ccsv5\f28335_flash_kernel
这个是TI的官方API例程，我通过仿真器下载到28335中，擦除flash成功。但是我将该API转换为BIN文件，通过串口发送到28335中，擦除FLASH失败，返回24.
具体过程如下：
编译工程生成.out,转换为hex再转换为bin，将28335切换到boot scia模式，通过串口助手发送API，之后API在28335的ram中执行（发送0x41返回0x41），但是执行到擦除flash时失败，返回24。
发生以下两种现象：
1.通过仿真器下载API后，擦除flash成功，此时如果去掉仿真器，保证28335不断电，进入boot scia模式，串口助手发送api，擦除flash成功。
2.一旦28335重新上电后，串口助手发送api，擦除flash每次失败，返回24.
排除hex转bin时错误，因为该转换工具用了比较久了，28062 api和其他dsp程序都是通过同样方式转换的，一直都是正常的；
排除28335硬件问题（如供电问题、芯片问题等），因为使用C2Prog来烧写，同样也是SCI方式，擦除flash每次都正常。
该问题卡了一段时间了，网上查找该问题，都是2014年前的，且没有留下正确详细的解决方式。
不知道为什么会这样，仿真器烧写后不断电发送API成功，重新上电后就不成功；TI例程的API与C2Prog的API又有什么区别呢？我又该如何解决我的问题？
手上有28335的大神能否帮忙测试一下TI的API在你们这是否是正常的？
希望得到TI工程师或各路大神的指点与帮助。
feiyu yu：
已经解决
controlSUITE3.4.7\device_support\f2833x\v142\DSP2833x_examples_ccsv5\f28335_flash_kernel
这个是TI的官方API例程，我通过仿真器下载到28335中，擦除flash成功。但是我将该API转换为BIN文件，通过串口发送到28335中，擦除FLASH失败，返回24.
具体过程如下：
编译工程生成.out,转换为hex再转换为bin，将28335切换到boot scia模式，通过串口助手发送API，之后API在28335的ram中执行（发送0x41返回0x41），但是执行到擦除flash时失败，返回24。
发生以下两种现象：
1.通过仿真器下载API后，擦除flash成功，此时如果去掉仿真器，保证28335不断电，进入boot scia模式，串口助手发送api，擦除flash成功。
2.一旦28335重新上电后，串口助手发送api，擦除flash每次失败，返回24.
排除hex转bin时错误，因为该转换工具用了比较久了，28062 api和其他dsp程序都是通过同样方式转换的，一直都是正常的；
排除28335硬件问题（如供电问题、芯片问题等），因为使用C2Prog来烧写，同样也是SCI方式，擦除flash每次都正常。
该问题卡了一段时间了，网上查找该问题，都是2014年前的，且没有留下正确详细的解决方式。
不知道为什么会这样，仿真器烧写后不断电发送API成功，重新上电后就不成功；TI例程的API与C2Prog的API又有什么区别呢？我又该如何解决我的问题？
手上有28335的大神能否帮忙测试一下TI的API在你们这是否是正常的？
希望得到TI工程师或各路大神的指点与帮助。
user4398920：
回复 feiyu yu:
你好 我也遇到了类似问题请问你是如何解决的
