Thread panic with PIC32MZ pic file #1
Comments
|
There is some "guessing code" that guesses the peripheral if there is no I spotted that the peripheral SFR name I would be happy to integrate a PR to make |
|
So I gave it a shot, adding in these two if statements to the guessing code: } else if ms == "DOS-01539_icd_jtag_pb_v2.Module" {
String::from("_ICDCON")
} else if ms == "DOS-02823_clk_cru_upb_v2.Module" {
String::from("REFQ1CON")I think that is what you were mentioning but I wasnt entirely sure. The second if came from a very similiar panic. However, now im hitting an assertion panic at 150 If you'd like here is the branch |
|
The assertion at line 150 is a consistency check of the source XML file, which failed. The SFR defintion that caused the error is The How to resolve this issue? Correcting the .PIC file manually? Always relying on the Currently, I tend to use |
|
I replaced some of the manual module checks that I added with a call to cloning the At this point, im not sure if im going about the correct path for these errors. I wish I knew why there were both I also looked at the PIC32MZ datasheet at table 7-3 and I didnt find |
|
I now have a running version. See below the changes I did (compared to my current version ignoring the Could you try it and check if the SVD file is Ok and correct if necessary? I selected the name "SYSBUS" for a system bus arbiter of the PIC32. Please change, should this name be not Ok. Please also trigger a PR (Pull Request) from your fork/branch. I would like to merge this into my repository. BTW, the register name is --- a/src/main.rs
+++ b/src/main.rs
@@ -146,8 +146,8 @@ fn analyze_periph(periph: &Element, periph_out_e: &mut Element) {
// get the phys. address and map it to the KSEG1 segment
let addr = parse_u32(&attr["_addr"]).unwrap() | 0xA000_0000;
- let name = &attr["name"];
- assert_eq!(name, &attr["cname"]);
+ let name = &attr["cname"];
+ //assert_eq!(name, &attr["name"]); // TODO: fix this
let mut portals = String::from("- - -");
if let Some(p) = attr.get("portals") {
@@ -171,14 +171,10 @@ fn analyze_periph(periph: &Element, periph_out_e: &mut Element) {
});
// guess peripheral
- let mop = match attr.get("memberofperipheral") {
- Some(m) => if m.len() == 0 { None } else { Some(m) },
- None => None,
- };
let mut cperi: String;
- if let Some(bop) = attr.get("baseofperipheral") {
+ if let Some(bop) = attr.get("baseofperipheral").filter(|s| ! s.is_empty()) {
cperi = bop.clone();
- } else if let Some(m) = mop {
+ } else if let Some(m) = attr.get("memberofperipheral").filter(|s| ! s.is_empty()) {
cperi = m.clone();
} else if let Some(grp) = attr.get("grp") {
cperi = grp.clone();
@@ -191,6 +187,18 @@ fn analyze_periph(periph: &Element, periph_out_e: &mut Element) {
String::from("PPS")
}else if ms == "DOS-01475_lpwr_deep_sleep_ctrl_v2.Module" {
String::from("DSCTRL") // Deep Sleep Controller
+ } else if ms == "DOS-01500_dma_bvci_v2.Module" {
+ String::from("DMAC2") // DMA of PIC32MZ
+ } else if ms == "DOS-01539_icd_jtag_pb_v2.Module" {
+ String::from("ICD") // ICD peripheral of PIC32MZ
+ } else if ms == "DOS-02823_clk_cru_upb_v2.Module" {
+ String::from("OSC") // OSC of PIC32MZ
+ } else if ms == "DOS-02508_adc_sar_ctrl_upb_v1.Module" {
+ String::from("ADC") // ADC on PIC32MZ
+ } else if ms == "DOS-02831_usb_clk_rst_v2.Module" {
+ String::from("USB") // PIC32MZ USB register map 2
+ } else if ms == "DOS-EIP-00136_ssx_v1.Module" {
+ String::from("SYSBUS") // PIC32MZ system bus arbiter
} else {
String::from("")
}; |
|
Thanks for the code, it worked great! I was able to convert it to a svd, then have the svd generate rust. However, after running the following code snippet as suggested by svd2rust, I tried generating the docs using Svd2rust commands$ svd2rust -i PICMZ.svd
$ rm -rf src
$ form -i lib.rs -o src/ && rm lib.rs
$ cargo fmtLast few errors from buildIf statement conflicting implementationsWhat are your thoughts on why its duplicating, is it originating from the edc file? As a side note some of the modules that show up in the if statement show up as a duplicate trait in the earlier output. |
|
I think the problem is that some |
|
I'm wondering how MPLAB properly handles it then, is it derived from somewhere else or from the other elements? Also, would the correct |
|
I do not know how they generate the C header files for the compiler and if/how other parts of MPLAB use the .PIC files. But the header files have a flat structure not including peripheral names. The datasheets list the available peripherals but do not consistently define symbolic names for them. In think the most pragmatic approach would be to figure out the peripheral names used in the .PIC files and then adapt the guessing code to process the |
|
I'm not sure if I know how to figure out the peripheral names from the .PIC file but i can attempt to give it a shot |
|
So I tried using the Update: I wasnt able to make a lot of progress on getting it to upload in any reasonable fashion, I will give it a shot later this week, any advice will be greatly appreciated though! |
|
I was able to get it to be hacked onto pic32-pac/pic32mx2xx, after which I tried to compile blinky two it and it threw many errors as one might expect. I suspect most of the errors come from trying to compile for a chip pic32-hal was never designed for. However, im not sure what needs to be fixed to help with the problem. Here are the errors if anyone wants to look them over |
|
I implemented the HAL modules for the PIC32MX and the respective PAC only. To test your new generated PAC and get something that at least compiles, I propose to write a blinky program that uses the PAC directly. If you plan to use the Rust low level runtime for the MIPS core, it makes sense to double-check the startup code in in BTW, to generate a flash hex image, you need to include appropriate configuration words, too (or at least check what happens if you leave then unprogramed (= 0xff)). If you do not want to fiddle with start-up code and configuration words you could consider compile the Rust program as a library and link it against a small C program that calls your Rust program. I never tried this but it should be possible. I hope this helps. Happy hacking ;) |
When running edc2svd on the PIC32MZ2048EFG100.PIC and it cause a thread panic. The file was acquired directly from an MPLABS install, so it should be a valid example of it.
It appears to be a purposeful panic with cperi.len() being 0 for the file, so im not sure where this comes from.
The text was updated successfully, but these errors were encountered: