ameba1的image tool使用

amebaz的image tool是使用uart下载的,ameba1的image tool是使用jlink下载的。

ameba1的操作

对于ameba1的image tool下载,操作方法如下:
GPIOB_0 上拉, 然后加电开机使得ameba1处理器进入烧录模式,然后image tool就可以连接和操作了。
需要注意的是,经过验证6.20c版本的jlink不行,可能更高版本的也不行。目前经过实际验证4.9版本的可以,其他版本需要自己去摸索和验证。

工具

ameba1 image tool
jlink 4.9

ameba mp bin档的制作

  1. 基线代码
    基线代码可以从官网下载或者从fae渠道获取。
    选择对应的工程基线,注意区分ameba1和amebaz系列。
    ameba1系列经实际操作,ameba1 v3.4b3 和ameba v4.0c都是可以的。
  2. 替换mp工程需要的lib库
    注意这个也是需要根据处理器的不同,找到对应的正确版本lib_wlan_mp.a。
    在默认的工程中,右键/lib/lib_wlan.a,选择option,选择 exclude from build,然后加入正确的lib_wlan_mp.a,最后重新编译就可以了。
    lib_wlan_mp.a的替换
  3. troubleshoot
    过程中遇到编译的bin开机hardfault error,和mptool无法连接的问题,经反复折腾都是基线版本的问题,无明显提示和解决方法

ameba1的mptool使用

realtek的rt8710af和rt8711af都归属于ameba1系列。

支持mptool的firmware

首先硬件的firmware必须是支持mptool的版本,支持的的版本运行时会显示如下类似的日志:

Initializing WIFI ...
RTL8195A[Driver]: The driver is for MP

日志中有mp字样的log。

连接硬件

连接时,要ameba芯片的GPIOB3脚接地,然后开机,再连接mptool,连接成功后,如下图所示:
mian
efuse
使用mptool前,注意参看工具目录下的使用手册,先进行正确的配置哦。

对应的软件和工具

支持mptool的firmware和mptool工具:
支持mptool的bin
mptool

jtag和swd接口线序

下面为J-Link接口定义:

仿真器端口 连接目标板 备注
1. VCC MCU电源VCC VCC
2. VCC MCU电源VCC VCC
3. TRST TRST Test ReSeT/ pin
4. GND GND或悬空
5. TDI TDI Test Data In pin
6. GND GND或悬空
7. TMS, SWIO TMS, SWIO JTAG:Test Mode State pin ; SWD: Data I/O pin
8. GND GND或悬空
9. TCLK, SWCLK TMS, SWCLK JTAG: Test Clock pin ; SWD: Clock pin
10. GND GND或悬空
11. RTCK RTCK
12. GND GND或悬空
13. TDO TDO Test Data Out pin|
14. GND GND或悬空
15. RESET RESET RSTIN pin|
16. GND GND或悬空
17. NC NC
18. GND GND或悬空
19. NC NC
20. GND GND或悬空

下面是管脚物理排列:
jtagswd

windows下实现esp32下载

  1. UI工具下载
    使用官方的UI工具 flash_download_tools 但是始终提示如下的错误:
wxBitmap::CreateFromImage(): invalid image

同时UI工具弹框提示:找不到 ./RESOURCE/IDLE_S.bmb
根据日志,对相关模组做了重新安装:

pip install -U wxPython
pip install Pillow

安装后还是不行,遂暂时另寻他法。
2. python命令行下载
想起ubuntu下 make flash 命令后的下载命令,一想,我可以在windows下如法炮制啊:

 ./esp32/esp-idf/components/esptool_py/esptool/esptool.py --chip esp32 --port COM15 --baud 115200 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 ./esp32/esp-proj/hello_world/build/bootloader/bootloader.bin 0x10000 ./esp32/esp-proj/hello_world/build/hello-world.bin 0x8000 ./esp32/esp-proj/hello_world/build/partitions_singleapp.bin

遇到问题:

No module named tools.list_ports

于是安装缺少的模块:

pip install pyserial --upgrade

再执行,同步重启设备,竟然顺利烧写成功了。
3. UI工具正常了
等方式2成功后,再尝试UI工具时,竟然顺利成功了。感情前面的失败是uart组件缺失导致的,日志提示真是坑啊。

最后还是一如既往的死磕,搞定!

ameba sdk的debugger设置

  1. setup

    两个配置项的内容:
$PROJ_DIR$\..\..\..\component\soc\realtek\8195a\misc\iar_utility\common\preload.mac
$PROJ_DIR$\..\..\..\component\soc\realtek\8195a\misc\iar_utility\common\8195a.ddf
  1. download

    配置内容:
    $PROJ_DIR$\tmp.board
  2. extra options

    配置内容:
    --drv_vector_table_base=0x0
    此选项如果没有设置,会出现 __vector_table 问题

IAR的link配置

不像STVD有详实的UI界面来配置详细的link参数,IAR无法无法细致的展现这些参数,那么如何配置这些参数呢,比如section,内存起始等。

在我们创建IAR的工程时,会生成EWSTM8目录,在目录下面的icf文件,就是默认iar工程加载的配置文件。没有的话,也可以自己修改或者从其他工程拿模板来修改。

STM8 bootloader纪要

STM8 bootloader-UM0560

mcu:STM8L051F3P6,属于 STM8L Series low density

bootloder 支持

已经内置bootloader的mcu
bootloader group

没有内置bootloader的mcu

bootloder 执行流程图

bootloader执行流程图:

bootloder 传输设置

ota 同步消息SYNCHR=0x7F

支持传输的外设

从图上看,051F支持UART或者SPI
UART设置:1 start bit, 8 data bit, 1 bit 奇校验 ,1 stop bit
波特率:通过0x7F的传输,自动适配波特率,最大115200,最小4800.

传输回复
串口:1 start bit, 8 data bit, no parity bit, 1 stop bit,波特率自适应

SPI设置
• 8 data bit, MSB first
• Bit rate: Set by the host which acts as a master
• Peripheral set in slave mode with software management of NSS
• Data polarity: CPOL = 0 (SCK to 0 when idle), CPHA = 0 (the first clock transition is the
first data capture edge).

收到命令后,bl回复ACK 0x79

bootloder 外设选择

从资源的角度,我们倾向于使用spi做外设,因为uart可以预留来做用户调试用,但是目前官方提供了uart的串口下载PC客户端,方便测试。所以目前看使用uart作为bl外设可能更方便。这里也就要求选用单片机时,最好是多串口的设备。

bootloder 跳转地址表

关键点检测后,要跳转的地址表:

目前我们可以先考虑实现串口的版本,但是最后还是SPI的更实用。

完整文档:UM0560

Apollo mcu的flash写入函数am_hal_flash_program_info异常

参考系统给的样例,封装了写入函数:

int usr_write_config_to_flash() {
  int ret;
  U32 offset = 0;
  // do {
  // 写入前要先擦除块
  info_block_erase();

  // 写入配置数据
  memset(flash_write_buf, 0, sizeof(flash_write_buf));
  memcpy(flash_write_buf, &sys_config, sizeof(sys_config));
  offset = 0;

  ret = am_hal_flash_program_info(AM_HAL_FLASH_PROGRAM_KEY,
                                  0, // we are only supporting INFO on instance 0.
                                  flash_write_buf,
                                  offset / 4,                    // offset
                                  (sizeof(sys_config) + 3) / 4); // num words
  //} while (ret);

  if (ret) {
    log(ERR, "am_hal_flash_program_info at offset 0x%08x i32ReturnCode = 0x%x.\n", offset, ret);
    return ERROR;
  }
  log(RUN, "flash write success\r\n");
  return SUCCESS;
}

系统的样例是正常的,因为没有别的业务逻辑,我的代码在开机执行也是正常的,但是在业务中调用 am_hal_flash_program_info 函数时就会随机失败,开始一直怀疑是地址区段的问题,各种尝试都不行,后来看函数的原型,发现下面的文字说明,才恍然一惊:

 

看到蓝色标识的部分,才想到是不是被系统的定时器中断影响了,因为系统起来后开启了很多定时器中断,于是在擦除和写入的逻辑区间关闭了中断,于是就没有再发现失败了。

浪费了半天时间,惭愧,特此随记,以示教训:在没有相关文档的情况下,要仔细看函数原型的任何一行说明文字

STM8 IWDG看门狗的使用说明

好久不搞stm8了,但朋友请教,还是帮忙确认下。主要是确认STM8的看门狗用法和喂狗时间问题,网上大把的代码样例,但是还是要刨根问底弄清楚细节,才可以用,否则就是埋雷。

大概的调用样例代码:

#define SYS_IWDG_OPEN        IWDG_KR=0xCC;
#define SYS_IWDG_FEED        IWDG_KR=0xAA;

void SystemIWDG_Config(void)   
{
    CLK_ICKCR|=S3;
    while((CLK_ICKCR&S4)==0);
    //STM8单片机需先执行0xCC指令,即先打开IWDG模块,否则IWDG工作不正常
    IWDG_KR=0xCC;                //启动看门狗
    IWDG_KR=0x55;                //使能模块访问
    IWDG_RLR=0xFF;               //溢出时间
    IWDG_PR=0x06;                //256分频 38000/256=148HZ T=6.7ms    
    IWDG_KR=0xAA;                //装载IWDG->RLR
}

代码的解释请参见以下的网络内容:

STM8独立看门狗介绍

独立看门狗模块可以用于解决处理器因为硬件或软件的故障所发生的错误。它由一个内部的128kHz的LSI阻容振荡器作为时钟源驱动,因此即使是主时钟失效时它仍然照常工作。

  • 独立看门狗功能说明
    图24是STM8独立看门狗模块的功能框图。
    当在键寄存器(IWDG_KR)中写入数值0xCC后,独立看门狗就被启动了,计数器开始从它的复位值0xFF开始递减计数,当计数减到0x00时就会产生一个复位信号(WDG RESET)。
    使用IWDG_PR和IWDG_RLR寄存器配置独立看门狗。IWDG_PR寄存器是用于选择驱动计数器时钟的预分频系数。每当KEY_REFRESH的数值(0xAA)写入到IWDG_KR寄存器时,独立看门狗将用IWDG_RLR的数值刷新计数器的内容,从而避免了产生看门狗的复位。
    IWDG_PR和IWDG_RLR寄存器具有写保护功能,要修改它们前,需首先在IWDG_KR寄存器写入KEY_ACCESS代码(0x55);在IWDG_KR写入0xAA将恢复写保护状态。

STM8_蜂鸣器功能图
(图24:STM8独立看门狗框图)

  • 硬件看门狗功能
    如果在IWDG_HW选择字节中使能了硬件看门狗的功能,在芯片上电时看门狗的功能被自动开启,如果软件不能及时操作键寄存器,则在计数器达到0x00时产生复位。关于选择字节的内容请参考数据手册中的说明。
  • 超时周期
    超时周期由计数器数值和时钟预分频器决定,下表列出了它们的数值。


(表26:STM8看门狗超时周期(假定计数器时钟为64kHz) )

键寄存器(IWDG_KR)

地址偏移值:0x00
复位值:未定义

STM8_键寄存器(IWDG_KR)

位7:0 KEY[7:0]:键值
软件必须在规定的时间内写入KEY_REFRESH数值,否则当计数器数值达到0时,看门狗会产生一个复位。
KEY_ENABLE数值=0xCC
写入KEY_ENABLE数值将启动IWDG。
KEY_REFRESH数值=0xAA
写入KEY_REFRESH数值将刷新IDDG。
KEY_ACCESS数值=0x55
写入KEY_ACCESS数值将允许对受保护的IWDG_PR和IWDG_RLR寄存器的操作

预分频寄存器(IWDG_PR)

地址偏移值:0x01
复位值:0x00

STM8_预分频寄存器(IWDG_PR)

位7:3 保留,必须保持为0。
位2:0 PR[2:0]:预分频系数
这些位是写保护的。它们用于指定对计数器时钟分频的分频系数。
000:分频系数=4
001:分频系数=8
010:分频系数=16
011:分频系数=32
100:分频系数=64
101:分频系数=128
110:分频系数=256
111:保留

重装载寄存器(IWDG_RLR)

地址偏移值:0x02
复位值:0xFF

STM8_重装载寄存器(IWDG_RLR)

位7:0 RL[7:0]:看门狗计数器重装载数值
这些位是写保护的(见14.2)。每次在IWDG_KR寄存器中写入0x
被传送到看门狗的计数器中,看门狗的计数器将重新从这个值开和时钟的预分频系数决定,见表26。

IWDG寄存器映像和复位数值


(表27:STM8 IWDG寄存器映像 )

 

官方手册原始内容,124页:

http://www.st.com/content/ccc/resource/technical/document/reference_manual/9a/1b/85/07/ca/eb/4f/dd/CD00190271.pdf/files/CD00190271.pdf/jcr:content/translations/en.CD00190271.pdf

本地下载备份:en.CD00190271

根据芯片手册中时钟的配置:

文章开头样例代码的看门狗最大喂狗时间大约1.725秒(38K时钟)

openwrt中添加mt7628an对sim7600ce的支持

按照模块的使用手册,我们知道设备的usb会虚拟出5个串口设备。
在openwrt中默认是支持usb转uart的驱动的,默认是可以支持此设备的,我们只要在menuconfig中选择相应的开关就可以完成支持

Kernel Modules → USB Support
<*> kmod-usb2
<*> kmod-usb-ohci
<*> kmod-usb-serial
                <*> kmod-usb-serial-option
                -*- kmod-usb-serial-wwan
<*> kmod-usb-core

LoRa技术介绍

目前看,LoRa是一个在IOT方案领域替换GSM的初步可行方案,主要从距离和功耗两个考虑方面。

介绍如下:
http://www.lora-alliance.org/What-Is-LoRa/Technology
http://www.rfwireless-world.com/Terminology/LoRa-technology-basics.html
http://www.rfwireless-world.com/Terminology/IoT-wireless-technologies.html

芯片厂商目前也已经有了量产的芯片可供评估,成本在1-2个美金。
http://www.microchip.com/design-centers/wireless-connectivity/embedded-wireless/lora-technology
http://www.semtech.com/wireless-rf/lora.html

hugo-md文档书写时的格式说明

前言

在决定使用github-hugo自动化流程后,第一个面临的问题就是,这个文档头的格式到底是什么样的,因为现在你要手写,就需要彻底搞清楚, 以便达到正确和高效。

阅读查找了gohugo.io的所有相关页面,找到以下两个相关的内容基本上说的很清楚了:
https://gohugo.io/content/front-matter/
https://gohugo.io/content/archetypes/

头格式

md只是文档的类型,但是里面的内容遵循怎样的格式呢? hugo目前支持3中toml,yaml,json,三种格式的文件头。识别符号分别如下

  • toml: +++
  • yaml: —
  • json: {}

toml示例:

+++
title = "spf13-vim 3.0 release and new website"
description = "spf13-vim is a cross platform distribution of vim plugins and resources for Vim."
tags = [ ".vimrc", "plugins", "spf13-vim", "vim" ]
date = "2012-04-06"
categories = [
  "Development",
  "VIM"
]
slug = "spf13-vim-3-0-release-and-new-website"
+++

Content of the file goes Here

yaml示例:

---
title: "spf13-vim 3.0 release and new website"
description: "spf13-vim is a cross platform distribution of vim plugins and resources for Vim."
tags: [ ".vimrc", "plugins", "spf13-vim", "vim" ]
date: "2012-04-06"
categories:
  - "Development"
  - "VIM"
slug: "spf13-vim-3-0-release-and-new-website"
---

Content of the file goes Here

json示例:

{
    "title": "spf13-vim 3.0 release and new website",
    "description": "spf13-vim is a cross platform distribution of vim plugins and resources for Vim.",
    "tags": [ ".vimrc", "plugins", "spf13-vim", "vim" ],
    "date": "2012-04-06",
    "categories": [
        "Development",
        "VIM"
    ],
    "slug": "spf13-vim-3-0-release-and-new-website",
}

Content of the file goes Here

字段变量

文档可以包含很多变量。

必要字段

  • tile: 内容的标题
  • description: 内容的描述
  • date:日期
  • taxonomies:分类字段,包括tag和categories

可选字段

  • aliases: 别名
  • draft: 是否是草稿
  • publishdate: 定时未来发布的时间
  • type: 内容的格式,可以从内容自动识别
  • isCJKLanguage:是否时CJK
  • weight: 排序的权重
  • markup: 时markdown格式还是reStructuredText
  • slug: url尾部的token
  • url: 完整的url

hugo markdown引擎的配置

finish!

Hanging Sockets and Power Consumption – Basics, Part 3

很好的文章,就mobile 空socket 的耗电状态做了深入的分析.

更完整的内容参见:trepn-whitepaper-apps-power

from:https://developer.qualcomm.com/blog/hanging-sockets-and-power-consumption-basics-part-3

Continuing our series on mobile apps and their effect on battery drain, I’ll pick up where the three guidelines in Wayne Lee’s last post left off, especially #3: “Know what your app is doing with the hardware and when it’s doing it.”

One common way that mobile apps use too much power is through hanging sockets –network connections that the app is no longer using, but which the server thinks are still alive because the app has not closed them. The subsequent query from the server results in needless battery drain.

Here’s more background on the problem and how you can deal with it.

“Wake up. It’s time to go to sleep.”

Applications often “forget” to close their socket after they are done with it. Then, after some amount of time without data activity, the server times the socket out and closes it.

Socket termination in TCP requires a four-way handshake, so the server has to send a FIN packet to the device, which usually takes the device from the low-power dormant state to the higher-power active state. The device goes idle for a bit, then back to dormant. It’s like waking somebody up to tell them that it’s time to go to sleep.

Look at the example in the diagram. The red (1) shows the device jumping from dormant to active mode to send and receive data normally for a few seconds. Once finished, the cellular radio drops to a power-saving idle mode (2) in case that it’s needed again. After about 15 seconds of inactivity, the radio goes dormant (3).

    The diagram shows inefficiencies in Socket Termination activity on a device, the multiple steps it goes through to send/receive data and why it’s important to close sockets.

But the app has left the socket open (hanging). The server doesn’t like loose ends, so it sends its FIN packet to the device. This rouses the radio from dormant to active again (4), the same as if it were sending/receiving data for the app. Worse yet, the radio follows the normal curve back down to idle for another 15 seconds, wasting more power (5).

Begin to get the idea?

The phone has to bring up the radio for a simple, easily avoidable handshake because the server has asked the device for something that the app should have provided in the first place. If no other traffic moves between the device and the network, the connection is a complete waste of several hundred milliamperes.

Assuming that the app uses the network four times in an hour, the simple fix of having the app close the socket when finished can reduce network power consumption by about 20 percent, which would be the difference between eight and ten hours of standby power.

The lesson is: Program your app to close sockets when it has finished with them. Otherwise, the phone consumes power to bring up the radio for a needless handshake with the server.

Next Steps

So, to paraphrase Wayne, you need to know what your app is doing with the cellular radio, when it’s doing it and how to turn it off when the app no longer needs it.

Questions? Visit the Trepn Profiler Support Forum or let me know in the comments below.