亚马逊Dash按钮和stm32的奇妙经历（下）

[复制链接]

丿灬幸灬发布时间：2018-11-1 11:11

技术贴
文章封面:	-
文章简介:	-

本帖最后由丿灬幸灬于 2018-11-2 21:56 编辑

GPIO映射

我已经把Cottonelle.bin的PrimFixGPIOPIN表映射到一些可读的源代码。在与MIXUSS64的工作交叉引用之后，这就是我们所得到的：

我们现在有一些潜在的选择。WSDE SDK对于其他数据结构中的GPIO如何声明和引用是一种快速而松散的操作，因此我可能需要更多的字节嗅探来确定是否可以收集更多关于platform_spi_mapping_t 和wiced_spi_device_t的信息。

更多的GPIO表挖掘

在这里，我在左边对齐了一些修改的GPIO PIN声明，并把它们映射到了原始Cottonelle.bin。紫色下划线是我怀疑数组结束的地方。我认为GPIOH TyPulfF*超出了范围。

寻找GPIO

在左边，我们有一个来自WiCED SDK 2.4.1二进制diff的示例应用程序，在更改了单个字节之后，它针对自身，因此我们可以找到到达GPIO表的方法。
在中间，示例应用程序。
在右边，一个类似的转储从DekuuKem的固件转储从棉布。
现在做一些测绘…

再回到 flash

让我们回到flash。我是想用st-flash, OpenOCD, pystlink,和 st-util+gdb，得到良好的闪存转储中案例我想回去与亚马逊的即插即用的软件。在与零字节填充内存是可能的，因此将继续读保护。

openocd的手册很好解锁flash命令

stm32f2 unlock 0

复制代码

由此产生了大量的输出

Debug: 19140 55145 target.c:2226 target_read_u32(): address: 0x40023c0c, value: 0x00010000
Debug: 19141 55145 stm32f2x.c:219 stm32x_wait_status_busy(): status: 0x10000
Debug: 19142 55146 hla_target.c:752 adapter_read_memory(): adapter_read_memory 0x40023c0c 4 1
Debug: 19143 55148 target.c:2226 target_read_u32(): address: 0x40023c0c, value: 0x00010000
Debug: 19144 55148 stm32f2x.c:219 stm32x_wait_status_busy(): status: 0x10000
Debug: 19145 55149 hla_target.c:752 adapter_read_memory(): adapter_read_memory 0x40023c0c 4 1
Debug: 19146 55150 target.c:2226 target_read_u32(): address: 0x40023c0c, value: 0x00010000
Debug: 19147 55150 stm32f2x.c:219 stm32x_wait_status_busy(): status: 0x10000
Debug: 19148 55151 hla_target.c:752 adapter_read_memory(): adapter_read_memory 0x40023c0c 4 1
Debug: 19149 55152 target.c:2226 target_read_u32(): address: 0x40023c0c, value: 0x00010000
Debug: 19150 55152 stm32f2x.c:219 stm32x_wait_status_busy(): status: 0x10000
Debug: 19151 55153 hla_target.c:752 adapter_read_memory(): adapter_read_memory 0x40023c0c 4 1
Debug: 19152 55154 target.c:2226 target_read_u32(): address: 0x40023c0c, value: 0x00010000
Debug: 19153 55154 stm32f2x.c:219 stm32x_wait_status_busy(): status: 0x10000

复制代码

然后我留下了一个空的flash，完全可以被丢弃，没有错误

亚马逊Dash UART输出

这是亚马逊Dash的UART一系列输出。

Oft DVT_1.0-Oft v0.9.119
Oft SW build on Oft Rev05 HW platform, custom version Mar 9 2015 19:50:48
Registration failure=0
RegGetFailure = 0
DumpRTCRegs: S=01000000 W=00000000 A=00000000 P=00000000 F=00000000 D=02000000 C=00000101 T=00000000
kVersion: 90011920
PWR flags: SB=0 LPWR=0 WWDG=0 IWDG=0 SFT=0 POR=1 PIN=1 BOR=1
Getting time in RTC_Init: GetRTCDateTime: 2088656913 Thu Feb 1 00:00:17 1900
MAC addr:tag = 0xbb len = 0x08 val = f0 27 2d 9b fb da
Serial:tag = 0xcc len = 0x12 val = 47 30 33 30 47 30 30 35 35 34 34 32 33 35 37 35
Key:tag = 0xaa len = 0x16 val = 4a 47 4d 49 53 4e 46 5a 32 4b 47 4e 59 51 50 53
32 46 33 31
post gBATTERYPercentage = (0%) [223]
VBAT = 0.223V (0%)
BOOT BATTERY CHECK : 0%
Low battery! 0% < 25%
DEAD BATTERY: 0% < 5% Shutting down power
shutdown called
Failed transactions = 0
iTOC_Pending_Rd = 0, iTOC_Next_Wr = 0Failed transactions = 0
Turning off power via latch switch
SEC_RetrToken returns bHaveRegToken 0
iTOC_Pending_Rd = 32768, iTOC_Next_Wr = 32768Failed transactions = 0
SyncTOC: rd 0x8000; wr 0x8000; tid 0x0; eod 0x0
while loop in TRANS_ThreaTimbeginbegin while true loop gUpTimeLimit 32000
**Device not registered
shutdown called
Failed transactions = 0
iTOC_Pending_Rd = 32768, iTOC_Next_Wr = 32768Failed transactions = 0
Turning off power via latch switch

复制代码

亚马逊供者2
随着第一个供者的加入，我们已经转移到第二个供者身上。一个高兴的按钮。
之前

之后

下移到30AWG，使用焊剂，和一个全新的铁尖。捐赠者在手术台上，连接着一个3.3V的eBay调节器、Adafruit 3.3V的FTDI UART和一个eBay ST-Link V2。

ST-Link V2也提供电力，但这对于一些用户来说已经足够了。

亚马逊Dash

这里没什么可看的。在dekuNukem的git仓库的精神下，一个Amazon Dash展开了。
我对把这个连接到我的ST-Link V2稍微感兴趣，因为用一个节点“黑客”它。在树莓派上运行的js或python脚本有点过时了……和作弊。

在这张照片拍摄完成后，26AWG的电线把SWCLK pad完全扯掉了。在谷歌上搜索一下，就会发现AXE610124与pad右侧的连接器头部吻合。我发现了SWDIO和其中一个引脚之间的连续性，所以它可能会起作用。我从Digi-Key订购了一些，我们看看会发生什么…

WiFiMCU引导装载程序

WiFiMCU引导加载程序显示一个有用的内存映射。

JTAG/SWD EMW3165引脚连接

ST-LINK V2	EMW3165/WiFiMCU
SWDIO	D6
GND	GND
SWCLK	D5
5.0V	VIN

EMW3165/WiFiMCU

eBay Mini ST-Link v2仿冒品和EMW3165/WiFiMCU。冒险始于尝试用texane的st-link工具备份WiFiMCU的固件。奇怪的是，flash转储很短，并且连续的flash转储没有匹配的输出。60-64字节在转储文件中被随机地归零。

使用gdb remote的OpenOCD似乎可以正常转储。之后的几个pull请求以及将ST-Link固件升级到V2J24S4解决了大部分问题。当将flash从0x8000000转储到0x8080000时，我可以从st链接得到几乎一致的输出，而7500中只有两个腐化的数据。

原文请见hackaday