STC32G12K128 芯片用 ISP 升级遇到的问题

steph***

jrc*** 发表于 2026-10-8 15:31
flash规划，要看keil里的配置，Options for Taget那个窗口中的设置。

如果flash规划，app区在 FF:0000到F ...

您好，再请教下，现在我的程序肯定小于 60K，按flash规划，app区在 FF:0000到FF:FFFF,

为什么写不成功？
因为eeprom你选4k,
那么eeprom的范围是FE:0000到FE：0FFF,
并没有覆盖app区，app区在FF:1000到FF:FFFF;  

那我升级的这段代码你的意思是 从地址 FF:0000 开始写？ 而且只写 4K?

但升级的地址是从上位机传下的，上位机肯定根据AP编译时的 INTVECTOR(0x1000) 和 地址保留 0xFF0003-0xFF1002, 但它是不只道 EEPROM 选择 4K的，所以上位机发送的升级地址应该还是 0XFF1000开始， 但可能是 ISP 修改了地址，但这个地址是从 FE:0000开始吗？

为什麽如果 EEPROM 选择 128K， 而 AP 是相同的，升级地址从 0xFF1000处开始呢？

jrc***

上面第三段问题：

从ff：1000开始写，写的大小为app的大小。不是固定4k。

上面第四段的问题：
上位机加载app后，复制ff：0000处的三字节到ff：1000处，发送擦除指令之后，开始发送写app的内容，
app的hex文件内容大概是这样：
xx地址，数据长L，数据[L];  多行。
上位机根据这个一行一行发下去。
mcu内收到后，照着传进来的地址，长度和数据，通过iap写，用户isp不会改地址。
上位机不管eeprom多大，直接传。
app有什么地址和数据，一一照传，也不会修改（除了前面说的ff：1000三字节）。
因为app本身就是从ff：1000开始，所以传输的是从ff：1000开始。
注：上位机我没看源码，不确定他会不会传第一行的ff：0000，即使传了也没事，因用户isp会过虑，前面有提到了,  这里假设会不传，下面同理）。

上面最后一段；
不管eeprom选128k，还是4k，app都是从ff：1000开始写，
区别是：选128k的能写成功，选4k的与不成功。

steph***

jrc*** 发表于 2026-10-8 22:52
上面第三段问题：

从ff：1000开始写，写的大小为app的大小。不是固定4k。

您好，这里 我还是想深究问题的原因在哪里....
  问 题 是  如果第一次下载 ISP + AP 代码，EEPROM 选 128K， 后续的 CAN 升级 可以 写入并升级成功， 但如果 第一次下载 ISP + AP 代码，EEPROM 选 4K， 后续的 CAN 升级 可以写入，但没有真正升级成功，现在 AP 代码肯定小于 60K.  

   上位机加载app后，复制ff：0000处的三字节到ff：1000处，发送擦除指令之后，开始发送写app的内容，
app的hex文件内容大概是这样：
xx地址，数据长L，数据[L];  多行。
上位机根据这个一行一行发下去。
mcu内收到后，照着传进来的地址，长度和数据，通过iap写，用户isp不会改地址。
上位机不管eeprom多大，直接传。
app有什么地址和数据，一一照传，也不会修改（除了前面说的ff：1000三字节）。
因为app本身就是从ff：1000开始，所以传输的是从ff：1000开始。   

  这里我也同意上述说法，但为何升级并未真正成功呢？

jrc***

我分开说 成功与不成功的例子对比一下：

成功的例子：
1，第一次下载isp+app，eeprom选128k，
烧录之后，mcu内记录下了eeprom为128k信息,
即iap可擦写范围是fe:0000到fe:0000+128k = fe:0000~ff:ffff。

2，之后，通过上位机升级，
上机传入mcu的app的地址是ff:1000到ff:1000+app实际大小，
这个地址在eeprom范围之内，所以写成功。

不成功的例子：
1，第一次下载isp+app，eeprom选4k，
烧录之后，mcu内记录下了eeprom大小为4k的信息。
即iap可擦写范围是fe:0000到fe:0000+4k = fe:0000~fe:0fff。

2，之后，通过上位机升级，
上位机传入mcu的app的地址是ff:1000到ff:1000+app实际大小，
这个地址不在eeprom范围之内，所以写不成功。

app的flash布局，可以在Objects\xxx.map文件中看。
下图：图1是Large模式的app, 图2是Huge模式的。//更正：图中标的文字“C库”为错误，应该为库代码。




xx.hex也可以简单看一下，

格式是:
:LLAAAATT[DD......]CC
开头”:"固定；
LL：数据字节数（1字节）
AAAA：16位起始地址（2字节）
TT：记录类型（1字节）
DD...：实际数据（n字节）
CC：校验和（1字节）

记录类型:共6种,具体可以百度， 这里说下 重要的类型0，和4

| 00 | 数据记录 | 存放实际程序代码或数据 |
| 04 | 扩展线性地址记录（HEX386） | 用于32位线性寻址， 地址的高16位。
如下图是
159行：0200000400FFFB
内容解析：长度=0x02, 地址=0x0000，记录类型=4, 数据=00FF,  意思是， 后续的地址的高位地址是00FF；
160行：0300000002100FDC
内容解析：长度=0x03, 地址=0x0000，记录类型=0, 数据=02100F,  数据意思是，LJMP 100F;

steph***

jrc*** 发表于 2026-10-10 11:25
我分开说 成功与不成功的例子对比一下：

成功的例子：

再次感谢您的答复，  

2，之后，通过上位机升级，
上位机传入mcu的app的地址是ff:1000到ff:1000+app实际大小，
这个地址不在eeprom范围之内，所以写不成功。

可不可以这样说，写之前，首先需要擦除，那 这些擦除的工作也并没有执行？ 擦除和写入都是在 ISP 中进行的，也就是ISP 接收到 上位机发送下来的 地址和数据，因为选了EEPROM 4K, 所以擦除被摒弃了？即使ISP 发出了擦除的指令

jrc***

steph*** 发表于 2026-10-12 10:34
再次感谢您的答复，  

2，之后，通过上位机升级，

通过上位机升级，是有先擦除再写app程序。
当用户ISP收到擦除指令时，通过IAP直接操作，但是它不管操作是否失败（和写app一样不管失败），也没有告诉上机位是否失败。
下图是can工程中的擦除代码，你可以看一下。

steph***

jrc*** 发表于 2026-10-12 10:46
通过上位机升级，是有先擦除再写app程序。
当用户ISP收到擦除指令时，通过IAP直接操作，但是它不管操作是 ...

好的，十分感谢您多日的耐心答复，再请教下
  这里为什麽非要选择USB 模式下载呢？ 选 USB LINK -UART 下载不更方便吗

jrc***

steph*** 发表于 2026-10-12 11:20
好的，十分感谢您多日的耐心答复，再请教下
  这里为什麽非要选择USB 模式下载呢？ 选 USB LINK -UART 下 ...

这个看个人喜好吧，有下载器，可以用下载器（usb转串口，或USB LINK)等。
在没有 下载器的情况下,
就用USB, 一根USB线就能用，连接变少了，也方便。

steph***

jrc*** 发表于 2026-10-12 11:55
这个看个人喜好吧，有下载器，可以用下载器（usb转串口，或USB LINK)等。
在没有 下载器的情况下,
就用US ...

好的，多谢多谢